Proposal / Discussion: Directive-based i18n & XLF support for large Next.js applications

[anuj9196]

Summary

We are evaluating a gradual migration of a large, long-running Angular application (Angular 18) to Next.js.

One major challenge we are facing is internationalization (i18n) developer experience, especially when compared to Angular’s built-in i18n system.

In Angular, we rely on:

• Directive-based marking of translatable strings:

<span i18n>Translate this</span>

• Automatic extraction to XLF (XLIFF) files
• Translation management via Weblate, with minimal developer overhead
• No need to manage or remember translation keys
• Clear readability during code reviews (the actual string is visible in the template)
• This model scales very well for large, complex, multi-language applications.

Problem Statement

In the Next.js / React ecosystem, most i18n solutions require:

<span>{t("translation_key")}</span>

This introduces several challenges at scale:

• Developers must invent and remember translation keys
• Code reviewers cannot see the actual text without referring to JSON files
• Large JSON files per locale become hard to maintain over time
• Existing XLF-based translation workflows (e.g. Weblate) cannot be reused directly
• Migration from Angular i18n becomes significantly more expensive

We have explored popular solutions (next-intl, next-i18next, react-intl, etc.), but none provide:

• Directive-like or JSX-native marking of translatable content
• First-class XLF/XLIFF support
• A zero-key, message-based authoring experience similar to Angular

What We’re Looking For

We’d like to start a discussion around whether Next.js (or the broader ecosystem) could support one or more of the following patterns:

• Directive / JSX-attribute based i18n

<span i18n>Translate this</span>

with build-time extraction.

• Message-as-key translation support

t("Translate this")

without requiring predefined JSON keys.

• First-class or recommended XLF/XLIFF workflows

  • Particularly for teams using translation platforms like Weblate
  • Even if XLF is converted to JSON at build time

• Official guidance or tooling

  • Codemods or Babel/SWC plugins for extracting translatable strings
  • Migration guidance for teams coming from Angular i18n

Why This Matters

As more large, enterprise Angular applications evaluate Next.js:

• i18n DX becomes a critical blocker
• Migration costs increase disproportionately due to translation refactors
• Teams with mature localization workflows struggle to adopt Next.js despite its many advantages (performance, ecosystem, AI tooling, etc.)

Improving this area would significantly lower the barrier for enterprise-scale migrations.

Additional information

No response

Example

No response