i18n

Content vs UI strings

Two separate systems localize two separate things:

• Content is what editors author on a form document: labels, placeholders, option labels, the response message. It is stored data, localized through Payload's own localization on the forms collection. Content fields are localized by default; the plugin option localizeContent: false opts a project out.
• UI strings are the plugin's own words: admin authoring labels and frontend renderer strings ("Add row", validation messages, poll notices). These are typed translations, overridden via the translations option (admin) and the t prop (frontend), below.

Admin strings

Field type names, rule labels and messages, action labels, and the rest of the authoring UI are typed translations under the formBuilder: namespace. English and German ship built in; override either, or add another locale, through the translations option:

import { formBuilder } from '@10x-media/form-builder'
import { keys } from '@10x-media/form-builder/i18n'

formBuilder({
  translations: {
    fr: { [keys.fieldTitle]: 'Titre' /* ... */ },
    de: { [keys.fieldTitle]: 'Bezeichnung' }, // key-by-key override of the built-in German
  },
})

@10x-media/form-builder/i18n exports keys, the built-in translations (en and de), and the TranslationKey / TranslationsOption types. A typo'd key fails to compile. Merge semantics and app-level overrides are shared across plugins: see Translations.

Frontend strings

The renderer is independent of the admin i18n: <Form> takes a t translator and a locale, which flow into every renderer and into value formatting:

<Form form={form} locale="de" t={(key) => myMessages[key] ?? key} />