Überblick

In gt-next 6.2.0 sind wir mit einem SWC-Plugin einen großen Schritt gegangen, um die Verarbeitung von der Laufzeit in die Build-Zeit zu verlagern. Dieser Ansatz eröffnet neue Möglichkeiten wie Compile-Time-Hashing, vorgerenderte Übersetzungen und strengere Validierung – alles ohne zusätzlichen Overhead zur Laufzeit.

Um den Fokus zu wahren, haben wir zunächst mit drei zentralen Verbesserungen begonnen:

• Compile-Time-Hashing
• Übersetzung bei Bedarf
• Linting-Regeln zur Build-Zeit

Hashing zur Compile-Zeit

Auch wenn es sich nur um eine relativ kleine Optimierung handelt, führen wir Hash-Berechnungen jetzt zur Build-Zeit statt zur Laufzeit aus.
Funktionen wie getGT() und serverseitiges <T> müssen nun nicht mehr bei jedem Aufruf Hashes berechnen und cachen, was zu einer konsistenteren Performance führt.

Übersetzung auf Abruf

Einer der größten Schmerzpunkte für Entwickler:innen war bisher, die Seite während der Entwicklung ständig neu laden zu müssen, um String-Updates in Echtzeit zu sehen.

getGT() und useGT() folgen dem vertrauten i18n-Muster:

export default function Page() {
  const t = useGT()
  // const t = await getGT(); für serverseitige Verwendung

  return (
    <>
      {t('zu übersetzender Inhalt')}
      {t('weiterer zu übersetzender Inhalt')}
    </>
  )
}

Wir haben t() bewusst synchron gehalten, um mit anderen i18n‑Libraries kompatibel zu sein. Der Nachteil war ein zweistufiger Übersetzungsprozess:

1. Registriere den Text bei der API.
2. Warte auf ein zweites Rendern, um das übersetzte Ergebnis anzuzeigen.

Jetzt wird dank des Compilers übersetzbarer Inhalt vorab gescannt und bereits zur Compile‑Zeit direkt an useGT() oder getGT() übergeben. Das bedeutet, Übersetzungen sind zur Laufzeit sofort verfügbar — ganz ohne Neuladen der Seite.

Linting zur Build-Zeit

Früher erforderte das Erkennen einer falschen Verwendung von <T>-Komponenten das Ausführen von gtx-cli mit einem benutzerdefinierten Linter. Dadurch kam es zu Inkonsistenzen zwischen dem Verhalten in Development und Production.

Seit 6.2.0 werden Linting-Regeln nun direkt im SWC-Plugin durchgesetzt. Wenn übersetzbarer Inhalt nicht in eine <T>-Komponente eingeschlossen ist, erhältst du einen Build-Fehler, sodass Probleme frühzeitig erkannt werden.

Warum SWC (vorerst)?

Unser Übergang von Runtime- zu Build-Time befindet sich noch in einem frühen Stadium. Wir starten mit Next.js, planen aber, bald weitere Frameworks zu unterstützen. Babel-Plugins mit derselben Funktionalität stehen bereits auf der Roadmap.

gt-next 6.2.0 legt das Fundament für einen schnelleren, zuverlässigeren Übersetzungs-Workflow. Indem wir Logik in die Build-Phase verlagern, reduzieren wir die Komplexität zur Laufzeit und machen Übersetzungen gleichzeitig unmittelbarer und berechenbarer.