Feature Request: Support useExtracted / getExtracted from next-intl in React Email

[bennajah]

Goals

1. Allow React Email templates to use useExtracted and getExtracted from next-intl@4.5+ for inline, keyless i18n.
2. Eliminate the need for manually managed JSON message catalogs and key-string lookups in email templates.
3. Make email i18n compatible with AI-assisted workflows and colocation-first development patterns.

Background

React Email currently supports next-intl via createTranslator, which requires:

1. Manually maintained JSON catalogs per locale (e.g. messages/en.json, messages/es.json).
2. Named keys for every string (e.g. t('welcome-email.header')).
3. Explicit locale prop threading throughout email components.

Reference: https://react.email/docs/guides/internationalization/next-intl

next-intl recently introduced useExtracted / getExtracted (available in next-intl@4.5, currently experimental), which takes a Tailwind-inspired approach to i18n:

• No keys: strings are written inline and keys are auto-generated and minified.
• No manual catalog management: the catalog is a compile output, not a source of truth.
• Colocated messages: translations live next to the component code, not in a separate file.
• ICU support and TypeScript validation: same feature parity as useTranslations.
• .po file support: optional GNU gettext format for richer translation context (descriptions, file references).

Reference:

• https://next-intl.dev/blog/use-extracted
• https://next-intl.dev/docs/usage/extraction

This pattern is increasingly the recommended approach for next-intl in Next.js apps, and email templates authored in that codebase will naturally reach for useExtracted alongside their other components.

Proposal

Update the React Email next-intl integration guide and ensure compatibility with the useExtracted / getExtracted APIs.

Specifically:

1. Documentation: Add a section (or a separate guide page) covering how to use useExtracted in email templates alongside the existing createTranslator guide, so developers can choose their preferred approach.

2. getExtracted for async templates: Since React Email templates are rendered server-side (and often as async components), document the use of getExtracted from next-intl/server as the primary path:

   import { getExtracted } from 'next-intl/server';
   
   export default async function WelcomeEmail({ name }) {
     const t = await getExtracted();
     return (
       <Html>
         <Preview>{t('Welcome to Acme')}</Preview>
         <Body>
           <Heading>{t('Welcome to Acme')}</Heading>
           <Text>{t('Hi {name}!', { name })}</Text>
           <Text>{t("Thanks for signing up! We're excited to have you on board.")}</Text>
           <Button href="https://example.com/dashboard">
             {t('Get Started')}
           </Button>
           <Text>
             {t('If you have any questions, reply to this email. We're here to help!')}
           </Text>
         </Body>
       </Html>
     );
   }

3. Preview environment compatibility: Clarify how useExtracted / getExtracted behaves in the React Email preview server (notably, next-intl docs state it works out-of-the-box in test environments without compilation). Verify this holds in the React Email dev preview and document any required setup.

4. Locale configuration: Document how to wire up getRequestConfig (or a simpler standalone config) so that locale resolution works when rendering email templates outside the Next.js request context (e.g. in a background job or API route).

5. Track stability: Since useExtracted is currently experimental in next-intl, this could initially ship as a "coming soon" or "experimental" section in the docs, with a stable guide once next-intl marks the API stable.