Entity Enricher 最多可同时生成 40 种语言的增强结果。多语言字段以语言为键的 JSON 对象形式存储——这种格式便于移植、可查询，并兼容所有主流数据库。
在 schema 编辑器中，在任何字符串或字符串数组属性上切换多语言标志。启用后，LLM 会返回以语言为键的对象包装的值，而不是普通值。
multilingual: true。multilingual: true 的描述、名称等）。点击其他任意语言块上的 ↑ 按钮可将其设为主语言。后端还会过滤掉 LLM 可能输出的、不在你所选范围内的多余语言键。dict[str, T]，其中键为 ISO 639-1 语言代码，值与字段类型匹配。多语言值以 JSON 对象形式存储，语言代码作为键。选择此格式而非其他方案，是因为它具有可移植性、可查询性和存储效率。
未设置 multilingual: true 的字段会以普通值返回。标识符、代码、URL、日期和数字通常保持非多语言。
多语言数组有两种处理方式。Entity Enricher 使用 格式 A（以语言为键的对象），因为这是唯一无需转换即可在所有主流数据库中直接使用的格式。
| 条件 | A 以语言为键的对象 | B 本地化项数组 |
|---|---|---|
| 结构 | {"en": [...], "fr": [...]} | [{"en": "x", "fr": "y"}, ...] |
| 查询一种语言 | 直接访问data -> 'field' -> 'en' | 需要迭代jsonb_array_elements + extract |
| 添加语言 | 为对象添加一个键 | 更新数组中的每一项 |
| 与标量保持一致 | 是——相同的 {"en": "...", "fr": "..."} 模式 | 否 — 字符串与数组的结构不同 |
| 数据库可移植性 | 所有主流数据库 | 所有主流数据库 |
以语言为键的格式在所有支持 JSON 列的主流数据库中都可原生查询。
提供 40 种语言。运行富化时可选择任意组合。
enEnglishzhChinesehiHindiesSpanisharArabicfrFrenchbnBengaliptPortugueseruRussianjaJapanesedeGermanurUrduviVietnamesetrTurkishkoKoreantaTamilmrMarathiteTelugupaPunjabiyueCantoneseitItalianplPolishukUkrainianroRomaniannlDutchelGreekcsCzechhuHungariansvSwedishsrSerbianbgBulgarianhrCroatianskSlovakdaDanishfiFinnishnoNorwegianltLithuanianslSlovenianlvLatvianetEstonianpreserve）多语言标志不能与 preserve 标志同时使用：受保留的值以单一语言原样传递，不做翻译。schema 编辑器会禁用相互冲突的开关，API 也会拒绝同时带有这两个标志的 schema。键字段（自然键或数据库键）可以是多语言的——此时 entity 标识将使用 schema 锁定的键语言。
多语言标志仅对某些属性类型有效。schema 编辑器会自动强制执行此规则。
| 属性类型 | 多语言？ | 输出格式 |
|---|---|---|
| string | 是 | dict[str, str] |
| number / integer | 是 | dict[str, float] |
| boolean | 是 | dict[str, bool] |
| 基本类型数组 | 是 | dict[str, list[str]] |
| object | 否 | 请改为标记对象内部的各个字段——除非该对象是每种语言一行，见下文 |
| 对象数组 | 否 | 改为标记项内部的各个字段 |
| $ref | 否 | 改为标记被引用实体内部的字段 |
多语言值是一个语言映射，而不是单个值——因此约束单个值的属性无法应用于它。这类冲突会在生成架构时解决，手动保存架构时则会被拒绝，而不会等到富集时才失败。
限定为固定成员集合的属性不能同时是多语言的：这些成员是规范化的标记，下游数据库会用它们约束某一列。翻译后的标签应放在你自己的查找表中，以该标记为键。
日期、UUID 或经正则校验的代码只有一种机器可读形式，而不是每种语言各有一种。同时兼具两者的属性无法保存。
保留值是原样返回的你自己的数据，因此没有什么需要翻译。
这一项是允许的。标识只在一种语言中解析——在架构首次发布到数据库时即固定下来——因此名称可以被翻译，而其标识不会随之改变。
有些数据源把语言建模为行：一个列表，其中每一项都带有一个语言代码及其自身的值，每种语言一项。这与多语言属性的结构不同，两者不可混用。生成过程会把这类属性识别为该对象的语言轴——前提是所观察到的每个值确实都是语言代码——随后为整个子树关闭内置的多语言机制。对对象通常建议的“逐个标记项内字段”做法在这里恰恰是错误的解法：它会为本已按语言分行的数据再生成一遍译文。
还有一个需要分清的区别：你增强到的语言是每次运行时的选择；架构自身文本（其描述和标签）所用的语言固定在架构上；而标识解析所用的语言按数据库固定。这是三项彼此独立的设置，但听起来都像是“语言”。
多语言支持贯穿富集流程的每个阶段。
融合来自多个模型的结果时，多语言字段会按语言进行比较。
| 场景 | 解析 |
|---|---|
| 模型在英语上一致，但在法语上存在分歧 | 这不算分歧。标识以本次运行的主语言判定，因此这算作一致：英文直接通过，法文则由按语言的合并规则处理。翻译差异永远不会提交仲裁——花钱让模型在两个都正确的译文之间做选择毫无意义 |
| 一个模型支持阿拉伯语，另一个则不支持 | 优先选择非空值（保留阿拉伯语） |
| 多语言数组在各模型间长度不同 | 每种语言中所有项的并集 |