# General Translation Changelog: gt-next 6.2.0: Traitement au build avec SWC
URL: https://generaltranslation.com/fr/blog/gt-next_v6_2_0.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 
Authors: Ernest McCarter
Published: 2025-08-19

## 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()`](/docs/react/nextjs/reference/functions/get-gt) et [`<T>`](/docs/react/reference/components/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()`](/docs/react/nextjs/reference/functions/get-gt) et [`useGT()`](/docs/react/reference/hooks/use-gt) suivent le modèle i18n habituel :

```tsx title="page.tsx" copy
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()`](/docs/react/reference/hooks/use-gt) ou [`getGT()`](/docs/react/nextjs/reference/functions/get-gt) 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>`](/docs/react/reference/components/t) nécessitait d&#39;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&#39;est pas encapsulé dans un composant [`<T>`](/docs/react/reference/components/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.

## Sitemap

See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.