Fix i18n type issue with multiple data content collections (#2611)

Co-authored-by: Chris Swithinbank <[email protected]>

.changeset/blue-walls-kiss.md

@@ -0,0 +1,5 @@
+---
+'@astrojs/starlight': patch
+---
+
+Fixes a UI string type issue in projects with multiple data content collections.

packages/starlight/utils/createTranslationSystem.ts

@@ -121,7 +121,11 @@ function buildResources<T extends Record<string, string | undefined>>(
 	return { [I18nextNamespace]: dictionary as BuiltInStrings & T };
 }
 
-export type I18nKeys = UserI18nKeys | keyof StarlightApp.I18n;
+// `keyof BuiltInStrings` and `UserI18nKeys` may contain some identical keys, e.g. the built-in UI
+// strings. We let TypeScript merge them into a single union type so that plugins with a TypeScript
+// configuration preventing `UserI18nKeys` to be properly inferred can still get auto-completion
+// for built-in UI strings.
+export type I18nKeys = keyof BuiltInStrings | UserI18nKeys | keyof StarlightApp.I18n;
 
 export type I18nT = TFunction<'starlight', undefined> & {
 	all: () => UserI18nSchema;

packages/starlight/utils/translations.ts

@@ -5,8 +5,13 @@ import type { i18nSchemaOutput } from '../schemas/i18n';
 import { createTranslationSystem } from './createTranslationSystem';
 import type { RemoveIndexSignature } from './types';
 
+// @ts-ignore - This may be a type error in projects without an i18n collection and running
+// `tsc --noEmit` in their project. Note that it is not possible to inline this type in
+// `UserI18nSchema` because this would break types for users having multiple data collections.
+type i18nCollection = CollectionEntry<'i18n'>;
+
 export type UserI18nSchema = 'i18n' extends DataCollectionKey
-	? CollectionEntry<'i18n'> extends { data: infer T }
+	? i18nCollection extends { data: infer T }
 		? i18nSchemaOutput & T
 		: i18nSchemaOutput
 	: i18nSchemaOutput;