Un glossaire donne au moteur de localisation un contrôle total sur des termes précis : soit en imposant une traduction exacte, soit en empêchant toute traduction. Les règles de glossaire priment sur le jugement du modèle, pour garantir une application cohérente à chaque requête.
Comment ça marche#
Chaque entrée de glossaire appartient à un moteur de localisation et s’applique à une paire langue source / langue cible donnée (ou * pour n’importe quelle langue). Lorsqu’il traite une requête de traduction, le moteur récupère les entrées de glossaire pertinentes via une recherche sémantique : il fait correspondre le sens du texte d’entrée aux termes enregistrés, et pas seulement des chaînes identiques.
| Champ | Description |
|---|---|
| Langue source | La langue du texte source, ou * pour n’importe quelle source |
| Langue cible | La langue du texte cible, ou * pour n’importe quelle cible |
| Texte source | Le terme dans la langue source |
| Texte cible | La traduction requise (ou le même terme, pour les éléments non traduisibles) |
| Type | custom_translation ou non_translatable |
| Hint | Contexte facultatif pour lever l’ambiguïté d’un terme (par ex. "nom, fonctionnalité produit") |
Types de glossaire#
Traductions personnalisées#
Imposez une traduction précise pour un terme. Le moteur utilisera toujours votre traduction à la place de celle du modèle.
| Texte source | Texte cible | Langue source | Langue cible |
|---|---|---|---|
| Deploy | Bereitstellen | en | de |
| 911 | 112 | en | de |
| workspace | espace de travail | en | fr |
Utilisez les traductions personnalisées pour :
- La terminologie produit avec des traductions déjà établies
- Les adaptations culturelles (numéros d’urgence, unités de mesure)
- Les termes pour lesquels le modèle choisit systématiquement le mauvais synonyme
Éléments non traduisibles#
Empêchez la traduction d’un terme. Le moteur conserve le texte source tel quel.
| Texte source | Texte cible | Type |
|---|---|---|
| Lingo.dev | Lingo.dev | non_translatable |
| OAuth | OAuth | non_translatable |
| GraphQL | GraphQL | non_translatable |
Utilisez les éléments non traduisibles pour :
- Les noms de marque et de produit
- Les protocoles et standards techniques
- Les noms propres qui doivent rester dans la langue source
Appariement sémantique#
Les entrées de glossaire sont appariées selon leur sens, et non par simple comparaison de chaînes. Lorsqu’il reçoit une requête de traduction, le moteur génère des embeddings pour le texte d’entrée et retrouve les entrées de glossaire dont les termes source sont sémantiquement proches.
Autrement dit, une entrée de glossaire pour "Deploy" correspondra aussi à "Deploying", "deployment" et "deploy your application", sans avoir à créer une entrée distincte pour chaque variante.
Champ Hint
Utilisez le champ Hint pour lever l’ambiguïté des termes qui ont plusieurs sens. Par exemple, une entrée de glossaire pour "bank" avec l’indication "financial institution" ne correspondra pas à "river bank" dans le texte d’entrée.
Langues génériques#
Définissez la langue source ou cible sur * pour appliquer une entrée de glossaire à toutes les paires de langues.
Cas fréquents :
| Texte source | Langue source | Langue cible | Cas d’usage |
|---|---|---|---|
| Lingo.dev | * | * | Ne jamais traduire le nom de marque, quelle que soit la langue |
| API | en | * | Conserver "API" non traduit dans toutes les langues cibles |
| Deploy | en | de | Utiliser une traduction allemande spécifique pour ce terme anglais |
Les entrées génériques et les entrées spécifiques à une langue se combinent : elles ne se remplacent pas.
Correspondance des langues#
Les entrées de glossaire s’appliquent aussi aux variantes régionales, pas uniquement aux codes de langue exacts. Une entrée de s’applique à de-DE ; une entrée de-DE s’applique à une requête de sans région. Des langues sœurs comme de-DE et de-AT ne partagent jamais leurs entrées. En cas de correspondances multiples, c’est la région par défaut du CLDR qui l’emporte. Les mêmes règles s’appliquent aussi aux voix de marque, aux instructions et aux configurations de modèle. Consultez Locale Resolution pour le comportement complet, y compris la règle de sécurité liée au script pour les traductions personnalisées.
Glossaire vs instructions vs voix de marque#
Chacun joue un rôle distinct dans la configuration du moteur :
| Glossaire | Instruction | Voix de marque | |
|---|---|---|---|
| Contrôle | Termes individuels | Règles linguistiques | Ton et style d’ensemble |
| Granularité | Terme par terme | Règle par règle | Par langue |
| Correspondance | Sémantique (par le sens) | Toutes incluses pour la langue | Toutes incluses pour la langue |
| Priorité | La plus élevée : prime sur le jugement du modèle | Intermédiaire : guide le modèle | La plus faible : pose le contexte |
| Exemple | "Deploy" → "Bereitstellen" | "Abréger Straße en Str." | "Utiliser le tutoiement, ton technique" |
Priorité des règles
Les termes du glossaire ont la priorité la plus élevée dans la hiérarchie des règles du moteur. Si une entrée de glossaire entre en conflit avec une instruction, c’est le glossaire qui l’emporte. Concevez vos instructions pour compléter le glossaire, pas pour le dupliquer.
Utiliser les glossaires avec l’API#
Les entrées de glossaire sont appliquées automatiquement lorsque vous appelez le endpoint localize. Le moteur récupère les entrées sémantiquement pertinentes pour la paire langue source / langue cible, puis les injecte dans le prompt.
Aucun paramètre supplémentaire n’est nécessaire : le moteur gère la récupération et l’injection automatiquement.
Gérer les glossaires via MCP#
Si vous utilisez le serveur MCP Lingo.dev, votre assistant de code IA peut gérer directement les entrées de glossaire :
"Add a glossary entry: translate 'workspace' to 'espace de travail'
for English to French.""Mark 'GraphQL' as non-translatable for all locales."