Aperçu

Dans gt-next 6.2.0, nous avons fait un grand pas en déplaçant une partie du traitement du runtime vers le build grâce à un plugin SWC. Cette approche débloque de nouvelles possibilités comme le hachage à la compilation, les traductions pré‑rendu, et une validation plus stricte — le tout sans ajouter de surcharge au runtime.

Pour rester concentrés, nous avons commencé modestement avec trois améliorations clés.

• Hachage à la compilation
• Traduction à la demande
• Règles de linting au moment du build

Hachage au moment de la compilation

Bien qu'il ne s'agisse que d'une optimisation relativement mineure, nous effectuons désormais les calculs de hachage au moment du build plutôt qu'à l'exécution.
Les fonctions comme getGT() et le composant <T> côté serveur n'ont plus besoin de calculer et de mettre en cache les hachages à chaque appel, ce qui se traduit par des performances plus régulières.

Traduction à la demande

L'un des principaux points de friction pour les développeurs a longtemps été de devoir actualiser la page pendant le développement pour voir les mises à jour des chaînes en temps réel.

getGT() et useGT() suivent le schéma i18n habituel :

export default function Page() {
  const t = useGT()
  // const t = await getGT(); côté serveur

  return (
    <>
      {t('du contenu à traduire')}
      {t('un autre contenu à traduire')}
    </>
  )
}

Nous avons délibérément gardé t() synchrone pour l'aligner sur les autres bibliothèques i18n. L'inconvénient était un processus de traduction en deux étapes :

1. Enregistrer le texte auprès de l'API. 2. Attendre un second rendu pour afficher le résultat traduit.

Désormais, grâce au compilateur, le contenu traduisible est analysé à l'avance et transmis directement à useGT() ou getGT() au moment de la compilation. Cela signifie que les traductions sont immédiatement disponibles à l'exécution — sans rechargement de page.

Analyse statique à la compilation

Auparavant, détecter une utilisation incorrecte des composants <T> nécessitait d'exécuter gtx-cli avec un linter personnalisé. Cela créait des incohérences entre le comportement en développement et en production.

Avec la version 6.2.0, les règles de linting sont désormais appliquées directement dans le plugin SWC. Si un contenu traduisible n'est pas encapsulé dans un composant <T>, vous obtiendrez une erreur à la compilation, ce qui garantit que les problèmes sont détectés en amont.

Pourquoi SWC (pour l’instant) ?

Notre transition du runtime vers la compilation n’en est encore qu’à ses débuts. Nous commençons avec Next.js, mais prévoyons de prendre en charge d’autres frameworks bientôt. Les plugins Babel offrant les mêmes fonctionnalités sont déjà sur notre feuille de route.

gt-next 6.2.0 pose les bases d’un flux de traduction plus rapide et plus fiable. En déplaçant la logique au moment de la compilation, nous réduisons la complexité à l’exécution tout en rendant les traductions plus immédiates et plus prévisibles.