FAQ

Questions et réponses courantes concernant le Compilateur Lingo.dev.

Puis-je traduire des chaînes littérales ?

Le Compilateur Lingo.dev suit la convention selon laquelle tout ce qui se trouve dans JSX est localisable. Les chaînes littérales en dehors des composants JSX ne sont pas localisées par conception.

Comportement actuel :

// Ceci NE sera PAS traduit
const message = "Hello world";
const errorText = "Something went wrong";

// Ceci SERA traduit
function Component() {
  return <h1>Hello world</h1>;
}

Rendre les littéraux localisables :

Vous pouvez rendre les chaînes littérales localisables en les enveloppant dans des fragments JSX :

// Avant : Non localisable
const message = "Hello world";

// Après : Localisable en utilisant des fragments
const message = <>Hello world</>;

// Utilisation dans votre composant
function Component() {
  return <div>{message}</div>;
}

Approche alternative :

// Pour les messages dynamiques
function getLocalizedMessage() {
  return <>Something went wrong</>;
}

// Pour le texte conditionnel
const statusText = isError ? <>Error occurred</> : <>Success</>;

Cette convention assure un comportement de localisation cohérent tout en maintenant des limites claires entre le contenu localisable et non localisable.

Nous explorons des moyens d'étendre ce comportement pour prendre en charge davantage de cas d'utilisation à l'avenir. Rejoignez notre Discord pour discuter des modèles spécifiques que vous aimeriez voir pris en charge.

Pourquoi mes composants basés sur des collections ne sont-ils pas traduits ?

Le compilateur présente actuellement une limitation avec les composants basés sur Adobe React-Aria/React-Stately qui attendent des collections comme enfants. Le contenu textuel direct dans les éléments de collection n'est pas automatiquement localisé.

Cela affecte des composants comme Select, Listbox, Menu, et d'autres composants similaires basés sur des collections provenant de bibliothèques telles que HeroUI, NextUI, et d'autres implémentations React-Aria.

Comportement actuel :

import { Select, SelectItem } from "@heroui/react";

export default function SelectExample() {
  return (
    <Select label="Select an animal">
      {/* Ce texte NE sera PAS traduit */}
      <SelectItem key="cat" textValue="Cat">
        Cat
      </SelectItem>
      <SelectItem key="dog" textValue="Dog">
        Dog
      </SelectItem>
    </Select>
  );
}

Solution de contournement :

Enveloppez le contenu textuel dans des fragments JSX pour le rendre localisable :

import { Select, SelectItem } from "@heroui/react";

export default function SelectWithWorkaround() {
  return (
    <Select label="Select an animal">
      {/* Ce texte SERA traduit */}
      <SelectItem key="cat" textValue="Cat">
        <>Cat</>
      </SelectItem>
      <SelectItem key="dog" textValue="Dog">
        <>Dog</>
      </SelectItem>
    </Select>
  );
}

Cette limitation affecte tout composant qui utilise le modèle de collection de React-Aria où le contenu textuel est transmis directement comme enfants aux éléments de collection. Nous travaillons à améliorer la prise en charge du compilateur pour ces cas.

Quels frameworks sont pris en charge ?

Lingo.dev Compiler prend actuellement en charge ces frameworks React :

  • Next.js (App Router uniquement)
  • React Router v6+
  • Remix (dernière version)
  • Vite + React

Nous accueillons les contributeurs intéressés par l'implémentation de la prise en charge du compilateur pour d'autres plateformes. Rejoignez notre Discord pour discuter des stratégies d'implémentation.

Puis-je ajouter d'autres langues ?

Oui ! Vous pouvez étendre la prise en charge des langues en configurant des modèles personnalisés directement dans votre configuration de compilateur :

const compilerConfig = {
  sourceLocale: "en",
  targetLocales: ["es", "fr", "de", "pt", "it"],
  models: {
    "*:pt": "mistral-saba-24b",
    "en:it": "meta-llama/llama-4-maverick-17b-128e-instruct",
    "*:*": "mistral-saba-24b",
  },
};

lingoCompiler.next(compilerConfig)(nextConfig);

Consultez la configuration avancée pour plus de détails.

Puis-je utiliser des prompts personnalisés ?

Oui ! Vous pouvez personnaliser les invites de traduction directement dans la configuration de votre compilateur :

const compilerConfig = {
  sourceLocale: "en",
  targetLocales: ["es", "fr", "de"],
  prompt:
    "Vous êtes un traducteur professionnel spécialisé dans la documentation technique. Traduisez de {SOURCE_LOCALE} vers {TARGET_LOCALE} tout en maintenant une précision technique.",
};

Pour des glossaires personnalisés, incluez les définitions de terminologie dans votre invite. Consultez notre invite par défaut pour les meilleures pratiques.

Puis-je utiliser davantage de fournisseurs LLM ?

Actuellement, le compilateur Lingo.dev s'intègre à Lingo.dev Engine et à plusieurs autres fournisseurs LLM.

Nous aimerions prendre en charge davantage de fournisseurs LLM prochainement - parlez-nous-en ou envoyez-nous une pull request !

Ai-je besoin d'une clé API GROQ dans le CI/CD ?

Généralement non. Si vous construisez votre application localement, toutes les traductions seront stockées dans le répertoire lingo/. Votre build CI/CD n'aura pas besoin d'appeler un LLM pour traduire des chaînes.

Alternativement, vous pouvez ajouter la variable GROQ_API_KEY à votre CI/CD et effectuer toutes les traductions lors du build, mais nous ne recommandons pas cette approche afin de garder un meilleur contrôle sur les traductions finales.

Puis-je modifier les traductions ?

Oui ! Vous pouvez modifier manuellement le fichier lingo/dictionary.js. Il exporte un objet contenant les traductions pour tous les fichiers et entrées. Vous pouvez modifier le texte pour chaque langue dans la propriété content. Vos modifications seront conservées tant que le texte source dans les composants React ne sera pas mis à jour.

Vous n'aimez pas éditer des objets JavaScript ? Nous lançons bientôt un éditeur pour améliorer l'expérience d'édition. Faites-nous savoir si cela vous intéresse !

Comment puis-je retraduire l'ensemble de mon application, un fichier spécifique ou une langue ?

Pour retraduire l'ensemble de votre application, supprimez le fichier dictionary.js du répertoire lingo/.

Pour retraduire uniquement des fichiers spécifiques, vous pouvez supprimer leur clé (nom de fichier) du fichier dictionary.js.

Si vous souhaitez retraduire une langue spécifique, vous devez supprimer tous les enregistrements pour cette langue.

Pourquoi dois-je construire l'application localement ?

Les builds locaux normalisent vos fichiers de traduction lingo/ en :

  • Supprimant les clés de traduction inutilisées
  • Mettant à jour les empreintes de contenu
  • Garantissant un formatage cohérent des fichiers
  • Optimisant pour le déploiement en production

Exécutez toujours npm run build avant de valider des modifications pour maintenir des fichiers de traduction propres.

Il manque des traductions !

Si des traductions manquent :

  1. Construisez localement pour normaliser vos fichiers lingo/ :

    npm run build

  2. Vérifiez que votre clé API est correctement configurée :

    # Vérifiez que votre fichier .env contient
GROQ_API_KEY=gsk_...

  3. Validez les fichiers mis à jour :

    git add lingo/
git commit -m "Mise à jour des traductions"

  4. Redémarrez votre serveur de développement après les modifications.

Puis-je configurer un glossaire personnalisé ?

Oui ! Utilisez des invites personnalisées pour définir la terminologie et les glossaires directement dans votre configuration de compilateur :

const compilerConfig = {
  sourceLocale: "en",
  targetLocales: ["es", "fr", "de"],
  prompt:
    "Vous êtes un traducteur professionnel. Utilisez ces termes de manière cohérente : 'Dashboard' doit être 'Tableau de bord' en français, 'Settings' doit être 'Configuración' en espagnol. Traduisez de {SOURCE_LOCALE} vers {TARGET_LOCALE}.",
};

Comment le compilateur gère-t-il la pluralisation ?

Le compilateur gère automatiquement les modèles de pluralisation de base, mais pour des règles de pluriel complexes, vous devrez peut-être structurer votre JSX en conséquence :

// Le compilateur gérera cela correctement
<p>{count === 1 ? <>1 élément</> : <>{count} éléments</>}</p>

Qu'en est-il des performances en production ?

Lingo.dev Compiler est optimisé pour la production :

  • Coût d'exécution nul - les traductions sont précompilées
  • Fractionnement des bundles - seule la locale active est chargée
  • Élagage des arbres - les traductions inutilisées sont supprimées
  • Compatible CDN - les fichiers de traduction statiques sont mis en cache efficacement

Puis-je utiliser ceci avec TypeScript ?

Oui ! Le compilateur fonctionne parfaitement avec les projets TypeScript. Tous les composants React fournis sont entièrement typés :

import { LocaleSwitcher } from "lingo.dev/react/client";

// Support TypeScript complet
const locales: string[] = ["en", "es", "fr"];
<LocaleSwitcher locales={locales} />;

Comment signaler des bugs ou demander des fonctionnalités ?

Prochaines étapes