Vue d’ensemble

Dans gt-next 6.2.0, nous avons franchi une étape importante pour faire passer le traitement de l’exécution à la phase de build grâce à un plugin SWC. Cette approche débloque de nouvelles possibilités, comme le hachage à la compilation, les traductions pré-rendues et une validation plus stricte — le tout sans surcoût à l’exécution.

Pour rester concentrés sur l’essentiel, nous avons commencé par trois améliorations clés.

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

Hachage à la compilation

Bien qu’il s’agisse d’une optimisation relativement modeste, nous effectuons désormais les calculs de hachage au build plutôt qu’à l’exécution. Des fonctions comme getGT() et <T> côté serveur n’ont plus besoin de calculer et de mettre en cache des hachages à chaque appel, ce qui garantit des performances plus constantes.

Traduction à la demande

L’un des principaux points de friction pour les développeurs était 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 modèle i18n habituel :

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

  return (
    <>
      {gt('some content to translate')}
      {gt('some other content to translate')}
    </>
  )
}

Nous avons délibérément conservé gt() synchrone pour rester cohérents avec les autres bibliothèques d’i18n. L’inconvénient, c’é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 build. Les traductions sont donc disponibles immédiatement à l’exécution — sans rechargement de la page.

Linting au build

Auparavant, détecter une mauvaise utilisation 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.

À partir de la version 6.2.0, les règles de linting sont désormais appliquées directement dans le plugin SWC. Si du contenu traduisible n'est pas encapsulé dans un composant <T>, vous obtiendrez une erreur de build, ce qui permet de détecter les problèmes plus tôt.

Pourquoi SWC (pour l’instant) ?

Notre transition de l’exécution vers le build n’en est encore qu’à ses débuts. Nous commençons avec Next.js, mais nous prévoyons bientôt de prendre en charge d’autres frameworks. Des plugins Babel offrant la même fonctionnalité figurent déjà sur la 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 build, nous réduisons la complexité à l’exécution tout en rendant les traductions plus immédiates et plus prévisibles.