Un glossaire donne au moteur de localisation un contrôle précis sur certains termes : il peut soit imposer une traduction exacte, soit empêcher toute traduction. Les termes du glossaire priment sur le jugement du modèle, pour garantir une application cohérente à chaque requête.
Un glossaire appartient à l’organisation : c’est un conteneur nommé qui regroupe des termes et s’applique à un moteur de localisation par rattachement. Un même glossaire peut piloter tous les moteurs qui en ont besoin, et un moteur peut en appliquer plusieurs.
Comment ça marche#
| Objet | Champs |
|---|---|
| Glossaire | Nom, description, langues source couvertes. Contient autant de termes que nécessaire. |
| Terme | Langue source, langue cible, texte source, texte cible, type, indication. |
Quand le moteur traite une requête de traduction, il récupère les termes pertinents dans tous les glossaires rattachés via une recherche sémantique : il fait correspondre le sens du texte d’entrée aux termes source enregistrés, et non à des chaînes exactes.
| 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") |
Les glossaires appartiennent à l’organisation#
| Action | Effet |
|---|---|
| Créer un glossaire | Il existe au niveau de l’organisation et ne s’applique à rien tant qu’il n’est pas rattaché |
| Le rattacher à un moteur | Tous ses termes deviennent récupérables pour les traductions de ce moteur |
| Le rattacher à plusieurs moteurs | Les mêmes termes s’appliquent à tous : une seule modification, et chaque moteur suit |
| Rattacher plusieurs glossaires à un moteur | Leurs termes sont réunis dans un même ensemble de récupération |
| Le détacher d’un moteur | Le moteur cesse de l’appliquer. Le glossaire et ses termes sont conservés. |
| Supprimer un glossaire | Refusé tant qu’un moteur l’applique encore : détachez-le d’abord. La suppression efface aussi ses termes. |
| Supprimer un moteur | Les glossaires et les termes restent en place. Ils appartiennent à l’organisation, pas au moteur. |
L’ordre de rattachement n’a aucune importance. Quand deux glossaires rattachés définissent le même texte source pour la même paire de langues, l’un comme l’autre peut l’emporter : mieux vaut garder un seul terme à un seul endroit.
Gérez les glossaires depuis Glossaries dans la barre latérale de l’organisation. L’onglet Glossary d’un moteur liste les termes qu’il applique actuellement et permet de rattacher ou détacher des glossaires.
Langues source#
Un glossaire indique quelles langues source il couvre. Un custom_translation dont la langue source n’en fait pas partie est refusé à l’écriture, sur tous les parcours, y compris le tableau de bord, l’API, une suggestion de moteur appliquée et le provisioning. La vérification utilise la même correspondance de langue permissive qu’en lecture, donc un glossaire couvrant en accepte un terme en-US.
Laissez les langues source vides, et le glossaire acceptera n’importe quelle langue source.
Les éléments non traduisibles sont exemptés : il n’y a pas de traduction en langue source à laquelle les rattacher. Ils ne sont aussi stockés qu’une seule fois avec une langue cible générique, quelle que soit la cible envoyée : le terme est protégé dans toutes les langues, donc créer des copies par langue ferait doublon.
Types de glossaire#
Traductions personnalisées#
Imposez une traduction précise pour un terme. Le moteur utilise 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, dans chaque langue cible.
| 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 termes du glossaire sont mis en correspondance par le sens, et non par comparaison exacte de chaînes. Quand le moteur reçoit une requête de traduction, il génère des embeddings pour le texte d’entrée et trouve les termes dont le texte source est sémantiquement proche.
Cela signifie qu’un terme pour "Deploy" correspond aussi à "Deploying", "deployment" et "deploy your application", sans nécessiter d’entrée distincte pour chaque variante.
Champ Hint
Utilisez le champ d’indication pour lever l’ambiguïté des termes qui ont plusieurs sens. Par exemple, un terme 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 un terme à 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 termes génériques et les termes spécifiques à une langue se combinent : ils ne se remplacent pas entre eux.
Correspondance des langues#
Les termes du glossaire s’appliquent aussi entre variantes régionales, et pas seulement entre codes de langue exacts. Un terme de s’applique à de-DE ; un terme de-DE s’applique à une requête simple en de. Des variantes sœurs comme de-DE et de-AT ne partagent jamais leurs termes. Quand plusieurs correspondent, la région CLDR par défaut l’emporte. Les mêmes règles s’appliquent aux voix de marque, aux règles et aux configurations de modèle. Consultez Locale Resolution pour le comportement complet, y compris la règle de sûreté liée au script pour les traductions personnalisées.
Glossaire vs. règles vs. voix de marque#
Chacun joue un rôle distinct dans la configuration du moteur :
| Glossaire | Règle | Voix de marque | |
|---|---|---|---|
| Contrôle | Termes individuels | Conventions linguistiques | Ton et style d’ensemble |
| Granularité | Terme par terme | Règle par règle | Texte par langue |
| Correspondance | Sémantique (par le sens) | Toutes les règles correspondantes incluses | Le seul texte qui correspond le mieux |
| 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" |
Tous les trois sont des conteneurs gérés au niveau de l’organisation qu’un moteur applique par rattachement : les glossaires contiennent des termes, les rulesets contiennent des règles, et une voix de marque contient un texte par langue.
Priorité des règles
Les termes du glossaire ont la priorité la plus élevée dans la hiérarchie du moteur. Si un terme du glossaire entre en conflit avec une règle, le glossaire l’emporte. Concevez les règles pour compléter le glossaire, pas pour le dupliquer.
Utiliser les glossaires avec l’API#
Les termes du glossaire s’appliquent automatiquement lorsque vous appelez le localize endpoint. Le moteur récupère, dans les glossaires qu’il applique, les termes sémantiquement pertinents pour la paire langue source / langue cible et les inclut dans le prompt. Aucun paramètre supplémentaire n’est nécessaire.
| Appel | Objectif |
|---|---|
POST /glossaries | Créer un glossaire pour l’organisation |
GET /organizations/:id/glossaries | Lister les glossaires de l’organisation avec le nombre de termes et de moteurs |
GET /glossaries/:id/glossary-items | Lister les termes d’un glossaire, regroupés par texte source |
POST /glossary-items avec glossaryId | Ajouter un terme à un glossaire |
PUT /engines/:id/glossaries | Remplacer l’ensemble des glossaires qu’un moteur applique |
DELETE /engines/:id/glossaries/:glossaryId | Cesser d’appliquer un glossaire à un moteur |
GET /engines/:id/glossary-items | Lister tous les termes qu’un moteur applique actuellement |
ownerEngineId sur POST /glossary-items fonctionne toujours : cela écrit dans le glossaire par défaut du moteur. Préférez glossaryId.
Accès#
org:glossary:read et org:glossary:edit régissent les glossaires et les termes qu’ils contiennent ; rattacher un glossaire à un moteur nécessite aussi engine:edit sur ce moteur. Une autorisation par glossaire donne à quelqu’un les droits de lecture et de modification sur un seul glossaire, au lieu de tous les glossaires de l’organisation. Voir Roles & Permissions.
Gérer les glossaires via MCP#
Si vous utilisez le serveur MCP Lingo.dev, votre assistant IA de développement peut gérer directement les glossaires et leurs termes :
"Create a glossary called Product terms covering English, and
apply it to the web engine.""Add a term: translate 'workspace' to 'espace de travail'
for English to French.""Mark 'GraphQL' as non-translatable for all locales."