feat: reference field type (storage-less edges + admin UI)

[MA2153]

What does this PR do?

Adds a reference field type end-to-end — a storage-less field that links entries via content-reference edges rather than a column on the collection's table.

Core (emdash)

• Reference fields are storage-less: the schema registry skips column DDL for them, and their values live as edges in _emdash_content_references instead of an ec_* column. Existing reference columns keep their data but are no longer written.
• Selections ride in the content create/update body under a references key and are written atomically with the entry in a single transaction; the content GET hydrates them alongside SEO and bylines.
• Each resolved reference carries a display title (from the entry's title, then name), so backlinks and picked entries show a readable label rather than a slug.
• A reference field's config (relation, target collection, multiple) flows through the admin manifest; its backing relation definition is created and removed together with the field, and the relation link is immutable across schema updates.
• Seed files apply a reference field's $ref: value as an edge (seed shape unchanged).
• Wires the previously-unregistered relation and reference-edge API routes into injectCoreRoutes.

Admin (@emdash-cms/admin)

• Configure a reference field in the schema editor (target collection, single/multiple).
• Pick and reorder referenced entries in the entry editor, saved with the entry in one request.
• Read-only "Referenced by" backlinks panel on referenced entries.

Closes #

Type of change

• Feature (requires maintainer-approved Discussion)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes (0 diagnostics)
• pnpm test passes (core: 4672 passed / 3 skipped; admin: 1065 passed)
• pnpm format has been run
• I have added/updated tests for my changes
• User-visible admin strings are wrapped for translation; no messages.po changes included in this PR
• I have added a changeset (emdash: minor, @emdash-cms/admin: minor)
• New features link to an approved Discussion: Complete the reference field: collection picker in schema editor + content picker in content editor #386

AI-generated code disclosure

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

Screenshots / test output

emdash   Test Files  352 passed | 1 skipped (353)
              Tests  4672 passed | 3 skipped (4675)

admin    Test Files   87 passed (87)
              Tests  1065 passed (1065)

🤖 Generated with Claude Code

Remains to be fixed

• Backlinks show a buffer in the sidebar even when they are not present
• Clicking "Add a reference" and not selecting anything, then clicking again, shows no items
• The way backlinks are listed should match the new sidebar aesthetics

Remains to be verified

• The search functionality in the content selector uses FTS, same mechanism as the admin's collection page
• The content selector functionality is an abstract and reusable component

[changeset-bot]

🦋 Changeset detected

Latest commit: bd97d0a

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

This PR includes changesets to release 16 packages

Name	Type
@emdash-cms/admin	Minor
emdash	Minor
@emdash-cms/cloudflare	Minor
@emdash-cms/sandbox-workerd	Patch
@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/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

[github-actions]

Scope check

This PR changes 3,014 lines across 34 files. Large PRs are harder to review and more likely to be closed without review.

If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs.

See CONTRIBUTING.md for contribution guidelines.

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

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

@emdash-cms/auth

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

@emdash-cms/auth-atproto

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

@emdash-cms/blocks

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

@emdash-cms/cloudflare

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

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

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

emdash

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

create-emdash

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

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

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

@emdash-cms/plugin-cli

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

@emdash-cms/plugin-types

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

@emdash-cms/registry-client

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

@emdash-cms/registry-lexicons

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

@emdash-cms/sandbox-workerd

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

@emdash-cms/x402

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

@emdash-cms/plugin-ai-moderation

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

@emdash-cms/plugin-atproto

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

@emdash-cms/plugin-audit-log

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

@emdash-cms/plugin-color

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

@emdash-cms/plugin-embeds

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

@emdash-cms/plugin-field-kit

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

@emdash-cms/plugin-forms

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

@emdash-cms/plugin-webhook-notifier

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

commit: bd97d0a

[emdashbot]

This PR implements the end-to-end reference field feature in a way that fits EmDash’s architecture: storage-less via _emdash_content_references, atomic writes inside the content create/update transaction, opt-in hydration on read, and admin picker/backlink UI. The approach is sound and matches the approved Discussion. I reviewed the diff, the changed handler/repository/component files, and the new route wiring without running the test suite or tooling.

There are a few real issues to fix before merge:

1. The ReferenceEntryRef Zod response schema does not include the new title field that resolveEntries returns, so OpenAPI/generated types drift from the runtime response.
2. The reference-field auto-loader in ContentEditor will retry forever when fetchReferenceChildren fails because the error path clears loading but leaves nextCursor set.
3. createFieldRelation validates the parent collection exists but never checks the target/child collection, allowing invalid reference fields via seeds or direct API calls.
4. The content picker does not filter by or preserve the active locale, which causes duplicate translation rows in multi-locale collections and means newly picked references lose their locale context.

Tests look thorough for the lifecycle and write paths, and the changeset wording is appropriate.

---

Findings

• [needs fixing] packages/core/src/api/schemas/relations.ts:89-98

  EntryRef/ReferenceEntryRef now carries a title field populated by resolveEntries, and the admin client type has it, but the Zod response schema was not updated. This causes the OpenAPI contract and any generated types to disagree with the runtime response.

  		// The actual locale of the resolved variant. When no variant matches the
  		// requesting entry's locale, the ref falls back to another locale's row;
  		// this field makes that substitution explicit instead of silently
  		// presenting a wrong-locale entry under the requested context.
  		locale: z.string().nullable(),
  		title: z.string().nullable(),
  		sortOrder: z.number().int().optional(),
  

• [needs fixing] packages/admin/src/components/ContentEditor.tsx:1684-1688

  ReferenceFieldRenderer auto-loads remaining pages whenever nextCursor && !loading. When handleLoadMoreReferences fails, it resets loading to false (line ~576) but leaves nextCursor intact, so this effect fires again immediately and can loop indefinitely on a failing API.

  Fix the error path so a failed load does not auto-retry. A minimal safe change is to track an error state (loadError) and include !loadError in this condition, then render a manual retry affordance when the load fails. Simply clearing nextCursor would stop the loop but would also unlock editing on a partial list and risk truncation on save.

• [needs fixing] packages/core/src/api/handlers/schema.ts:47-55

  createFieldRelation checks that the parent collection exists, but it never validates targetCollection. A reference field can therefore be created pointing to a non-existent collection (via seed or direct API), leaving a relation row and an admin picker that loads a missing collection.

  The standalone handleRelationCreate already validates both collections; createFieldRelation should do the same.

  	const parent = await registry.getCollection(collectionSlug);
  	if (!parent) {
  		throw new SchemaError(`Collection "${collectionSlug}" not found`, "COLLECTION_NOT_FOUND");
  	}
  	const child = await registry.getCollection(targetCollection);
  	if (!child) {
  		throw new SchemaError(
  			`Target collection "${targetCollection}" not found`,
  			"COLLECTION_NOT_FOUND",
  		);
  	}
  

• [suggestion] packages/admin/src/components/ContentPickerModal.tsx:32-39

  PickedContentEntry does not carry the chosen entry’s locale, so freshly picked references lose locale context: the editor can’t show the cross-locale badge and the link falls back to the active locale instead of the actual entry locale. Also, the content-list query below does not pass a locale filter, which makes multi-locale collections show duplicate translation rows. Consider threading the editor locale into fetchContentList and adding locale?: string here so the reference row can preserve the picked variant.

[MA2153]

Item 4 (duplicate loses reference edges) confirmed and fixed. Added RelationRepository.copyParentEdges(fromParentGroup, toParentGroup) and wired it into handleContentDuplicate inside the existing duplicate transaction. It copies only the original's outgoing edges (parent side), preserving relation/child/sort order — backlinks pointing at the original are intentionally left alone. Added an integration test asserting the duplicate (a distinct translation group) carries the same children in order.

[emdashbot]

This re-review confirms the reference field implementation remains the right approach for EmDash: storage-less edges, atomic transaction writes, opt-in hydration, and admin picker/backlink UI. It matches the approved Discussion and the broader architecture.

The only prior-review concern that is clearly resolved is the auto-paging retry loop in ContentEditor.tsx: the error state now halts fetchReferenceChildren retries when a page fails, so a broken API no longer spins.

Three issues from the previous review are still unaddressed in this push and need attention before merge:

1. The entryRefSchema in packages/core/src/api/schemas/relations.ts does not include the title field that resolveEntries returns at runtime. This creates an OpenAPI/generated-type contract drift from the actual response.
2. createFieldRelation in packages/core/src/api/handlers/schema.ts still validates only the parent collection and not the target/child collection, leaving a defense-in-depth gap.
3. PickedContentEntry in packages/admin/src/components/ContentPickerModal.tsx still doesn't carry locale, and fetchContentList isn't scoped to one, so multi-locale collections show duplicate translation rows and newly picked references lose locale context.

Tests and changesets look appropriate. The first two are blocking enough to hold a clean merge; the third is a UX/localization suggestion that aligns with EmDash's per-locale content model.

---

Findings

• [needs fixing] packages/core/src/api/schemas/relations.ts:89-93

  The entryRefSchema object still omits the title field that resolveEntries populates from the referenced entry's title/name data. The EntryRef TS type in api/handlers/relations.ts, the admin client type, and the ContentItem.references shape all include it, but this Zod response schema does not. That drifts the OpenAPI contract and any generated clients from the runtime response, and a parse/serialize pass through the schema would strip the display title.

  Add title after collection to match the runtime EntryRef order:

  		id: z.string(),
  		slug: z.string().nullable(),
  		collection: z.string(),
  		title: z.string().nullable(),
  		// The actual locale of the resolved variant. When no variant matches the
  		// requesting entry's locale, the ref falls back to another locale's row;
  		// this field makes that substitution explicit instead of silently
  		// presenting a wrong-locale entry under the requested context.
  		locale: z.string().nullable(),
  		sortOrder: z.number().int().optional(),
  

• [needs fixing] packages/core/src/api/handlers/schema.ts:48-50

  The createFieldRelation helper still validates that collectionSlug exists but never checks targetCollection. Because this helper is also called from seeds and direct registry code paths, a missing or invalid target collection leaves a relation row pointing at a non-existent child collection. The standalone handleRelationCreate already validates both collections; createFieldRelation should too.

  	const parent = await registry.getCollection(collectionSlug);
  	if (!parent) {
  		throw new SchemaError(`Collection "${collectionSlug}" not found`, "COLLECTION_NOT_FOUND");
  	}
  
  	if (!(await registry.getCollection(targetCollection))) {
  		throw new SchemaError(
  			`Target collection "${targetCollection}" not found`,
  			"COLLECTION_NOT_FOUND",
  		);
  	}
  
  	const baseName = `${collectionSlug}_${fieldSlug}`.slice(0, 63);
  

• [suggestion] packages/admin/src/components/ContentPickerModal.tsx:32-33

  PickedContentEntry still doesn't carry the selected entry's locale, and the fetchContentList call at line 116 isn't scoped to one either. In multi-locale collections this means duplicate translation rows appear in the picker, and a freshly picked reference loses its locale context (so ContentEditor can't show the cross-locale badge or link to the actual picked variant until hydration refreshes it).

  Consider:

  1. Adding locale?: string to PickedContentEntry and locale?: string to ContentPickerModalProps so callers can pass the editor's active locale.
  2. Passing locale: item.locale when building picked objects (around lines 136 and 147).
  3. Threading that locale into fetchContentList so the list is scoped to the locale the editor is working in.

[MA2153]

Addressed in 850285f.

1. entryRefSchema missing title — added title: z.string().nullable() between collection and locale, matching the runtime EntryRef. Contract no longer drifts.

2. createFieldRelation target not validated — now checks targetCollection exists and throws COLLECTION_NOT_FOUND, mirroring handleRelationCreate. It runs inside the field-create transaction, so an invalid target rolls back with no orphan field/relation row. Added a lifecycle test (rejects creating a reference field whose target collection does not exist).

3. Picker locale — handled differently, because reference edges are keyed by translation_group and are therefore locale-agnostic. Rather than thread a per-pick locale:

   • Removed the cross-locale <Badge> from both the reference list and the backlinks sidebar. Labelling a resolved variant's locale implies a per-locale binding the edge doesn't have, which is misleading.
   • The displayed title already resolves at the editing entry's locale via pickVariant(variants, locale) (falling back only when that locale genuinely has no row), which matches what public rendering shows.

   I'm declining the fetchContentList locale-scoping suggestion: because edges key on the translation group, scoping the picker to one locale would hide valid targets whose group only has a row in another locale. The "duplicate translation rows" the review describes don't occur in practice — verified locally in the admin.

[emdashbot]

The reference field implementation continues to be the right approach for EmDash: storage-less edges, atomic transaction writes, opt-in hydration, and admin picker/backlink UI. It fits the approved Discussion and the broader per-locale content model.

Of the three issues raised in the previous review, two are clearly resolved in this push:

• entryRefSchema now includes title and locale, matching the runtime EntryRef shape.
• createFieldRelation now validates both the parent and target collections.

One previously-flagged issue is still unaddressed: ContentPickerModal does not carry or pass locale information, so multi-locale collections show duplicate translation rows and newly picked references lose their locale context.

This re-review also found two new contract/convention gaps:

1. handleContentGet hydrates item.references, but contentItemSchema does not declare it, so OpenAPI / generated clients drift from the runtime response.
2. references is now a runtime-hydrated top-level ContentItem property but is not in RESERVED_FIELD_SLUGS, so a user-defined field with that slug collides with the hydrated object.

Authorization on the new reference edge routes is correct (own + content:edit_own on writes, content:read on reads), the relation lifecycle mirrors the existing taxonomy translation pattern, seed $ref: values are routed to edges, and changeset/test coverage looks appropriate. None of the findings are security or data-loss blockers, so this is a comment review.

---

Findings

• [needs fixing] packages/core/src/api/schemas/content.ts:157-179

  handleContentGet sets item.references when referenceOptions is passed (see packages/core/src/api/handlers/content.ts), and the runtime ContentItem type already includes it. The public contentItemSchema does not, so the OpenAPI/generated client contract drifts from the actual single-item response — a pass through this schema would strip reference hydration.

  Import entryRefSchema from ./relations.js and add references after seo:

  import { bylineSummarySchema, bylineCreditSchema, contentBylineInputSchema } from "./bylines.js";
  import { cursorPaginationQuery, httpUrl, localeCode } from "./common.js";
  import { entryRefSchema } from "./relations.js";
  

  		locale: z.string().nullable(),
  		translationGroup: z.string().nullable(),
  		seo: contentSeoSchema.optional(),
  		references: z.record(
  			z.string(),
  			z.object({
  				children: z.array(entryRefSchema),
  				nextCursor: z.string().optional(),
  			}),
  		).optional(),
  	}).meta({ id: "ContentItem" });
  

• [needs fixing] packages/admin/src/components/ContentPickerModal.tsx:32

  This is the same locale concern from the previous review and is still unaddressed. PickedContentEntry has no locale, ContentPickerModalProps has no locale prop, and fetchContentList is called without one. On a multi-locale install the target collection's content list returns every translation, so the picker shows duplicate translation rows; when an entry is picked, the editor can't know its locale, so links lose the ?locale= context and the cross-locale badge/behavior cannot work until the next hydration round-trip.

  Make three small changes:

  1. Add locale to PickedContentEntry and ContentPickerModalProps.
  2. Pass the active locale into fetchContentList so the result is scoped to the editor locale.
  3. Preserve the picked item's locale when building the PickedContentEntry objects (around togglePicked and handleSingleChoose).

  export interface PickedContentEntry {
  	collection: string;
  	id: string;
  	slug: string | null;
  	title: string;
  	locale?: string;
  }
  
  interface ContentPickerModalProps {
  	open: boolean;
  	onOpenChange: (open: boolean) => void;
  	collection?: string;
  	multiple?: boolean;
  	selectedIds?: ReadonlySet<string>;
  	onConfirm: (rows: PickedContentEntry[]) => void;
  	title?: string;
  	/** Active editor locale. When set, the list is scoped to that locale. */
  	locale?: string;
  }
  

  	const { data, isLoading, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfiniteQuery({
  		queryKey: ["content-picker", activeCollection, trimmedSearch, locale],
  		queryFn: ({ pageParam }) =>
  			fetchContentList(activeCollection, {
  				limit: 50,
  				cursor: pageParam,
  				search: trimmedSearch || undefined,
  				locale,
  			}),
  

  				next[item.id] = {
  					collection: activeCollection,
  					id: item.id,
  					slug: item.slug,
  					title: getItemTitle(item),
  					locale: item.locale,
  				};
  

• [needs fixing] packages/core/src/schema/types.ts:317-334

  handleContentGet now hydrates item.references as a top-level ContentItem property, alongside terms, bylines, and byline. Those existing runtime-hydrated fields are reserved so user-defined fields cannot shadow them, but references is missing. A collection with a non-reference field named references would return both data.references and references in the response, causing confusion and making the schema contract impossible to satisfy cleanly.

  Add references to the reserved list after byline:

  	// Runtime-hydrated fields
  	"terms",
  	"bylines",
  	"byline",
  	"references",
  

[MA2153]

Re: review — addressed two of the three, declining the third.

#1 — contentItemSchema missing references — fixed. Added references: z.record(z.string(), referenceChildrenResponseSchema).optional() to contentItemSchema, reusing the existing referenceChildrenResponseSchema rather than re-inlining the shape. (Note: the schema is only consumed by OpenAPI doc generation, not runtime serialization, so nothing was actually being stripped — but the doc drift was real.)

#2 — ContentPickerModal locale — fixed, but not by locale-scoping the query. Hard-filtering the list to the editor locale would hide valid targets: reference edges are keyed by translation_group, so an entry that only exists in another locale is still a legitimate pick (this is exactly why the reference-list resolver's pickVariant falls back across locales). Instead the picker now fetches all translations and collapses them to one row per translation_group using the same semantics — prefer the editor locale, fall back to the lowest locale code — and the picked row carries its variant's locale so links/badges keep context before hydration. The locale prop is optional; callers that omit it (menus) short-circuit to the previous behavior unchanged.

#3 — reserve references in RESERVED_FIELD_SLUGS — declining. RESERVED_FIELD_SLUGS exists to stop user-defined fields from shadowing values hydrated onto entry.data — terms/bylines/byline, written in query.ts. references is never hydrated onto entry.data; it's a top-level item.references set only by the editor GET path (resolveEntries has no other call site). A user field named references therefore yields data.references (their value) alongside top-level item.references — distinct keys, no shadowing, no data loss. Reserving it prevents no real collision, and adding a new reserved slug would break any existing install that already has a references field on its next schema edit. Leaving it unreserved.

[emdashbot]

Re-review of the reference field feature.

The storage-less reference-field approach is still the right fit: edges live in _emdash_content_references, writes are atomic inside the content transaction, hydration is opt-in, and the admin picker/backlink UI follows the existing patterns. The previously-flagged schema gaps are closed in this push:

• contentItemSchema now declares the runtime-hydrated references shape via referenceChildrenResponseSchema.
• entryRefSchema carries title and locale.
• createFieldRelation validates both the parent and target collections.

Two issues from the last review remain partially or fully unaddressed:

1. Content picker still fetches across all locales. ContentPickerModal now accepts locale and threads it into the picked row, but it does not send locale to fetchContentList or include it in the query key. The server returns every translation; the modal only collapses them client-side. That still produces duplicate rows when translations exist, and switching locales while the modal is cached can show the wrong variant. It also means selectedIds (which holds a concrete entry id) can miss a translation-group sibling that the picker happens to render.

2. references is still not a reserved field slug. handleContentGet now places resolved reference children at item.references, alongside terms, bylines, and byline. Those siblings are reserved, but references is missing. A collection with a non-reference field named references would emit both data.references and a top-level references, shadowing the hydrated value and making the contract impossible to satisfy.

I also found one new low-severity item: the docstring at the top of the manifest test file describes the pre-fix behavior and contradicts the test it introduces.

Security/auth, transaction routing, seed edge writes, relation lifecycle, and changeset/test coverage are otherwise in good shape. No blockers, so this is a comment review.

---

Findings

• [needs fixing] packages/admin/src/components/ContentPickerModal.tsx:124-131

  The locale prop is now carried on PickedContentEntry and used for client-side translation-group collapsing, but it is not passed to the server request or included in the query key. fetchContentList supports a locale filter, so the picker currently fetches every translation and then collapses them in memory. That still produces duplicate translation rows in multi-locale collections and makes the cached result wrong when the active locale changes. It also means selectedIds (concrete entry ids) can miss sibling variants rendered by the locale collapse.

  Add locale to the query key and forward it to fetchContentList:

  	const { data, isLoading, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfiniteQuery({
  		queryKey: ["content-picker", activeCollection, trimmedSearch, locale],
  		queryFn: ({ pageParam }) =>
  			fetchContentList(activeCollection, {
  				limit: 50,
  				cursor: pageParam,
  				search: trimmedSearch || undefined,
  				locale,
  			}),
  		initialPageParam: undefined as string | undefined,
  		getNextPageParam: (lastPage) => lastPage.nextCursor,
  		enabled: open && !!activeCollection,
  	});
  

• [needs fixing] packages/core/src/schema/types.ts:333-334

  handleContentGet now hydrates references as a top-level ContentItem property (alongside terms, bylines, and byline). Those existing runtime-hydrated properties are reserved so user-defined fields cannot shadow them, but references is missing. A collection with a non-reference field slug of references would return both data.references and a top-level references, making the response contract and any generated types impossible to satisfy cleanly.

  Add references to the runtime-hydrated reserved list:

  	// Runtime-hydrated fields
  	"terms",
  	"bylines",
  	"byline",
  	"references",
  ];
  
  

• [suggestion] packages/core/tests/integration/manifest-reference.test.ts:1-8

  The docstring at the top of the file says _buildManifest copies validation for repeater/file/image fields "but not reference fields", but the test below asserts that reference-field validation is included after this PR. The stale explanation is confusing and contradicts the test.

  Update the comment to match the current behavior, e.g.:

  /**
   * `_buildManifest` copies `field.validation` into the manifest descriptor
   * for repeater/file/image/reference fields so the admin editor can drive
   * the reference picker widget with the field's `relation`,
   * `targetCollection`, and `multiple` config.
   */
  

[MA2153]

References are keyed by translation groups; they step-aside the entry's locale. We decide which title to show based on the current entry's locale (the one being edited). Once you translate the current entry to a different locale, its references automatically show titles in the new locale if they have that translation. Navigating to references determines the correct ID based on the same mechanism as the title.