Résolution des langues

Chaque entrée de glossaire, voix de marque, instruction et configuration de modèle est enregistrée pour une langue. Lorsque le moteur traite une demande de traduction, il détermine quelles entrées enregistrées s’appliquent à la langue de la requête : correspondances exactes, héritage entre variantes régionales et repli lorsqu’aucune entrée exacte n’existe. La même logique de résolution s’applique à ces quatre surfaces 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.

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).

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.

Compatibilité des écritures#

Une règle supplémentaire s’applique uniquement aux entrées de glossaire custom_translation, dont le texte est associé à une orthographe précise. Une langue de base avec une écriture ambiguë — sr (cyrillique ou latin), zh (simplifié ou traditionnel) — doit préciser l’écriture à l’enregistrement, soit via 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 totalement nu, sans écriture ni région, est rejeté. À la lecture, ces formes explicites sont équivalentes : un glossaire enregistré comme zh-Hans-CN s’applique à une requête zh-CN, et inversement. En revanche, une requête zh sans précision, dont l’écriture est inconnue, ne récupère pas une entrée liée à une écriture donnée ; pour obtenir des résultats prévisibles, indiquez donc explicitement une écriture ou une région. Les langues qui n’utilisent qu’une seule écriture, comme de, n’ont pas besoin de précision supplémentaire et résolvent normalement de vers de-DE. Les entrées non_translatable sont transmises telles quelles, 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 le glossaire, la voix de marque et les instructions 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 endpoint. Le moteur fait correspondre la sourceLocale et la targetLocale de la requête aux glossaires, voix de marque, instructions et configurations de modèle enregistrés — aucun paramètre supplémentaire n’est nécessaire.

Étapes suivantes#