|
Documentation
Réserver une démoPlateforme
Plateforme
MCPCLIAPIWorkflows
GuidesChangelog

Premiers pas

  • Introduction
  • Connectez votre moteur

Moteur de localisation

  • Vue d'ensemble
  • Voix de marque
  • Règles
  • Glossaires
  • Modèles LLM
  • Jetons de cache
  • Résolution des langues

Qualité

  • Rapports
  • Évaluateurs IA
  • Playground
  • Suggestions du moteur

Admin

  • Clés API
  • Équipe
  • Rôles et autorisations
  • Journaux d’audit

Résolution des langues

Chaque terme du glossaire, texte de voix de marque, règle et configuration de modèle est enregistré pour une langue donnée. Lorsque le moteur traite une demande de traduction, il détermine quelles entrées enregistrées s’appliquent à la langue de la requête : correspondance exacte des codes, héritage entre variantes régionales et repli lorsqu’aucune entrée exacte n’existe. Ce même mécanisme de résolution s’applique aux quatre types de configuration.

Fonctionnement#

Les langues sont normalisées dans une forme canonique à l’entrée, puis enregistrées et renvoyées sous cette forme. La casse et les délimiteurs sont corrigés ; les sous-étiquettes sont conservées.

Vous saisissezEnregistré sous
ENen
en_USen-US
sr_Latn-RSsr-Latn-RS
zh-cnzh-CN

La correspondance fonctionne dans les deux sens au niveau des sous-tags : une langue enregistrée s’applique à une requête si l’une correspond exactement à l’autre ou en est un ancêtre. Deux graphies d’une même langue correspondent également lorsque ni l’une ni l’autre n’est ancêtre de l’autre, mais la région détermine l’écriture : les formes avec région seule et celles précisant l’écriture sont équivalentes (zh-CN ≡ zh-Hans-CN, zh-TW ≡ zh-Hant-TW).

EnregistréS’applique àNe s’applique pas à
dede, de-DE, de-AT, de-CH-
de-DEde-DE, dede-AT, de-CH (régions sœurs)
zh-CNzh-CN, zh-Hans-CN, zhzh-TW, zh-Hant-TW (écriture différente)

Héritage inversé

Le cas où un de-DE enregistré répond à une requête simple de est de loin le plus courant en pratique : la plupart des moteurs sont configurés avec des codes régionaux complets, mais reçoivent des requêtes avec un code de base. Les deux sens sont pris en charge.

Résolution en cas de correspondances multiples#

Lorsque plusieurs entrées enregistrées s’appliquent, le moteur les classe et retient la meilleure :

  • Correspondance exacte ou langue par défaut d’abord. Pour une requête de, de-DE (la région par défaut du CLDR pour l’allemand) est préféré, puis le simple de.
  • La plus spécifique ensuite, pour départager.
  • Toute autre région correspondante reste disponible en repli : un client dont la seule entrée est de-CH l’obtient quand même pour une requête de lorsqu’aucune meilleure correspondance n’existe, afin qu’aucune configuration ne se retrouve jamais orpheline.
RequêtePréféréS’applique aussi (repli)Exclus
dede-DE, puis dede-CH, de-AT-
de-DEde-DE, puis de-de-AT, de-CH
de-ATde-AT, puis de-de-DE, de-CH

Classement ou sélection#

Le classement ci-dessus détermine l’ordre pour les types de configuration qui se combinent, et le gagnant pour ceux qui n’en retiennent qu’un :

Type de configurationRôle du classement
GlossaireTous les termes correspondants peuvent être récupérés ; la pertinence sémantique détermine ce qui est envoyé dans le prompt
RèglesToutes les règles correspondantes sont incluses, en commençant par la langue la plus proche
Voix de marqueLe texte qui correspond le mieux l’emporte : un seul texte de voix de marque s’applique par requête
Configurations de modèleLa meilleure correspondance devient le modèle principal ; les autres constituent la chaîne de repli

Compatibilité des écritures#

Une règle supplémentaire s’applique uniquement aux éléments du glossaire custom_translation, dont le texte est lié à une orthographe précise. Une langue de base avec une écriture ambiguë — sr (cyrillique ou latin), zh (simplifié ou traditionnel) — doit préciser une écriture à l’enregistrement, soit sous la forme d’une écriture explicite (zh-Hans, sr-Cyrl), soit via une région qui en détermine une (zh-CN → simplifié, sr-RS → cyrillique, selon le CLDR). Seul un code véritablement nu, sans écriture ni région, est rejeté. À la lecture, ces formes explicites sont équivalentes : un terme enregistré comme zh-Hans-CN s’applique à une requête zh-CN, et inversement — mais une requête zh nue, dont l’écriture est inconnue, ne récupère pas une entrée associée à une écriture ; envoyez donc une écriture ou une région explicite pour obtenir des résultats prévisibles. Les langues qui n’utilisent qu’une seule écriture, comme de, n’ont pas besoin d’écriture et résolvent normalement de vers de-DE. Les éléments non_translatable sont transmis tels quels, quelle que soit l’écriture.

Exemple#

Un moteur configuré avec des codes régionaux (en-US vers fr-FR, de-DE, nb-NO) et recevant des requêtes en code de base (fr, de, no) :

  • Une cible fr récupère les termes du glossaire, le texte de voix de marque et les règles de fr-FR — classés comme valeur par défaut pour fr, et non comme solution de dernier recours — car fr-FR est la région par défaut du CLDR pour le français.
  • Une source en correspond aux entrées en-US — la correspondance est bidirectionnelle.
  • Une cible no ne récupère pas nb-NO. no et nb sont des sous-étiquettes de langue différentes, pas une paire de régions ; utilisez nb comme cible.

Utiliser la résolution des langues avec l’API#

La résolution s’effectue automatiquement lorsque vous appelez le point de terminaison localize. Le moteur fait correspondre la sourceLocale et la targetLocale de la requête avec les termes du glossaire, les textes de voix de marque, les règles et les configurations de modèle qu’il applique — sans paramètre supplémentaire.

Étapes suivantes#

Glossaires
Associez les termes source à des traductions exactes par langue
Voix de marque
Définissez le ton général et le niveau de formalité par langue
Règles
Ajoutez des règles linguistiques regroupées en jeux de règles
Modèles LLM
Configurez la sélection des modèles et les replis par langue

Cette page vous a-t-elle été utile ?

Max PrilutskiyMax Prilutskiy·Mis à jour il y a environ 1 mois·4 min de lecture