Entity Enricher peut produire des résultats d'enrichissement dans jusqu'à 40 langues simultanément. Les champs multilingues sont stockés sous forme d'objets JSON indexés par langue — un format portable, interrogeable et compatible avec toutes les grandes bases de données.
Dans l'éditeur de schéma, activez l'indicateur multilingue sur toute propriété de type chaîne ou tableau de chaînes. Une fois activé, le LLM renvoie des valeurs encapsulées dans un objet indexé par langue au lieu d'une valeur simple.
multilingual: true dans le schéma JSON.multilingual: true). Utilisez le bouton ↑ sur toute autre puce pour la promouvoir comme langue principale. Le backend filtre également les clés de langue parasites que le LLM pourrait émettre en dehors de votre sélection.dict[str, T], où les clés sont des codes de langue ISO 639-1 et les valeurs correspondent au type du champ.Les valeurs multilingues sont stockées sous forme d'objets JSON avec les codes de langue comme clés. Ce format a été retenu parmi d'autres pour sa portabilité, sa facilité d'interrogation et son efficacité de stockage.
Les champs sans multilingual: true sont renvoyés comme valeurs simples. Les identifiants, codes, URL, dates et nombres restent généralement non multilingues.
Deux approches existent pour les tableaux multilingues. Entity Enricher utilise le Format A (objet indexé par langue), car c'est le seul format qui fonctionne tel quel dans toutes les principales bases de données sans transformation.
| Critères | A Objet indexé par langue | B Tableau d'éléments localisés |
|---|---|---|
| Structure | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| Interroger une seule langue | Accès directdata -> 'field' -> 'en' | Nécessite une itérationjsonb_array_elements + extract |
| Ajouter une langue | Ajoutez une clé à l'objet | Mettre à jour chaque élément du tableau |
| Cohérent avec les scalaires | Oui — même motif {"en": "...", "fr": "..."} | Non — structure différente pour les chaînes et les tableaux |
| Portabilité de la base de données | Toutes les principales bases de données | Toutes les principales bases de données |
Le format indexé par langue est nativement interrogeable dans toutes les grandes bases de données prenant en charge les colonnes JSON.
40 langues sont disponibles. Sélectionnez n'importe quelle combinaison lors de l'exécution d'un enrichissement.
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve)L'indicateur multilingue ne peut pas être combiné avec l'indicateur preserve : une valeur préservée est transmise sans traduction, dans une seule langue. L'éditeur de schéma désactive la bascule en conflit, et l'API rejette les schémas portant les deux indicateurs. Les champs clés (clés naturelles ou de base de données) peuvent être multilingues — l'identité de l'entité utilise alors la langue de clé verrouillée du schéma.
L'indicateur multilingue n'est valide que sur certains types de propriétés. L'éditeur de schéma applique cette règle automatiquement.
| Type de propriété | Multilingue ? | Format de sortie |
|---|---|---|
| string | Oui | dict[str, str] |
| number / integer | Oui | dict[str, float] |
| boolean | Oui | dict[str, bool] |
| tableau de primitives | Oui | dict[str, list[str]] |
| object | Non | Marquez plutôt les champs individuels à l'intérieur de l'objet — sauf si l'objet contient une ligne par langue, voir ci-dessous |
| tableau d'objets | Non | Marquer plutôt les champs individuels à l'intérieur des éléments |
| $ref | Non | Marquer plutôt les champs à l'intérieur de l'entité référencée |
Une valeur multilingue est une table de langues, pas une valeur unique — les attributs qui contraignent une valeur unique ne peuvent donc pas s'y appliquer. Ces conflits sont résolus à la génération du schéma et refusés lorsque vous en enregistrez un à la main, plutôt que d'échouer plus tard, à l'enrichissement.
Une propriété restreinte à un ensemble fixe de membres ne peut pas être multilingue en plus : les membres sont des jetons canoniques, et une base consommatrice contraint une colonne à partir d'eux. Les libellés traduits ont leur place dans votre propre table de correspondance, indexée sur le jeton.
Une date, un UUID ou un code validé par expression régulière n'a qu'une seule forme lisible par machine, pas une par langue. L'enregistrement d'une propriété qui cumule les deux est refusé.
Une valeur préservée est votre donnée renvoyée telle quelle : il n'y a donc rien à traduire.
Celle-ci est autorisée. L'identité est résolue dans une seule langue — fixée pour le schéma lors de sa première publication vers une base de données — de sorte qu'un nom peut être traduit sans que son identité ne change.
Certaines sources modélisent la langue sous forme de lignes : une liste dont chaque élément porte un code de langue et ses propres valeurs, une par langue. Cette forme diffère d'une propriété multilingue, et les deux ne doivent pas être mélangées. La génération reconnaît une telle propriété comme l'axe linguistique de l'objet — uniquement si chaque valeur observée est bien un code de langue — puis désactive le mécanisme intégré pour tout ce sous-arbre. Marquer les champs individuels à l'intérieur de l'élément, le conseil habituel pour les objets, est ici exactement le mauvais remède : vous obtiendriez des traductions de lignes qui sont déjà à raison d'une par langue.
Une distinction de plus à garder en tête : les langues dans lesquelles vous enrichissez se choisissent à chaque exécution ; la langue dans laquelle est rédigé le texte propre à un schéma (ses descriptions et libellés) est fixée sur le schéma ; et la langue dans laquelle l'identité est résolue est fixée par base de données. Trois réglages distincts qui ressemblent tous à « la langue ».
La prise en charge multilingue est intégrée à chaque étape du pipeline d'enrichissement.
Lors de la fusion des résultats de plusieurs modèles, les champs multilingues sont comparés par langue.
| Scénario | Résolution |
|---|---|
| Les modèles s'accordent sur l'anglais mais divergent sur le français | Pas un désaccord. L'identité est jugée dans la langue principale de l'exécution : cela compte donc comme un accord : l'anglais passe tel quel, et le français est tranché par la règle de fusion par langue. Les écarts de traduction ne sont jamais envoyés à un arbitre — payer un modèle pour choisir entre deux traductions correctes, ce serait dépenser pour rien |
| Un modèle prend en charge l'arabe, un autre non | Préférer la valeur non nulle (l'arabe est conservé) |
| Les tableaux multilingues diffèrent en longueur selon le modèle | Union de tous les éléments par langue |