每条术语表、品牌语调、指令和模型配置都绑定到一个区域设置。引擎处理翻译请求时，会判断哪些已存储条目适用于该请求的区域设置——包括精确匹配、跨区域变体继承，以及在没有精确匹配时进行回退。这套解析逻辑对这四类配置一视同仁。
工作原理#
区域设置在输入时会先规范化为标准格式，随后也会以该格式存储并返回。大小写和分隔符会被统一修正，子标签则会完整保留。
| 输入值 | 存储为 |
|---|---|
EN | en |
en_US | en-US |
sr_Latn-RS | sr-Latn-RS |
zh-cn | zh-CN |
匹配会跨越子标签边界双向生效——只要存储的区域设置与请求完全一致，或其中一方是另一方的上级，就会视为适用。
| 已存储 | 适用于 | 不适用于 |
|---|---|---|
de | de、de-DE、de-AT、de-CH | - |
de-DE | de-DE、de | de-AT、de-CH（同级区域） |
反向继承
已存储的 de-DE 响应不带地区的 de 请求，是现实中最常见的主流模式：大多数引擎按完整地区代码配置，但收到的往往是基础语言代码请求。两个方向都支持。
多个匹配项如何决出结果#
当有多个已存储条目同时适用时，引擎会对它们排序，并采用最优项：
- 精确匹配或语言默认项优先。 对于
de请求，会优先选择de-DE（德语的 CLDR 默认地区），其次才是不带地区的de。 - 其次看谁更具体，作为决胜规则。
- 其他任何匹配地区仍会保留为回退项——如果某个客户唯一的条目是
de-CH，那么在de请求没有更优匹配时，依然会使用它，因此配置永远不会被搁置。
| 请求 | 首选 | 同样适用（回退） | 排除 |
|---|---|---|---|
de | de-DE，然后是 de | de-CH、de-AT | - |
de-DE | de-DE，然后是 de | - | de-AT、de-CH |
de-AT | de-AT，然后是 de | - | de-DE、de-CH |
文字系统安全性#
还有一条额外规则仅适用于术语表中的 custom_translation 条目，因为这类文本绑定到特定书写体系。对于文字系统存在歧义的基础语言——如 sr（西里尔字母或拉丁字母）、zh（简体或繁体）——写入时必须明确指定文字系统（sr-Cyrl、sr-Latn、zh-Hans、zh-Hant）。像 de 这样只有单一文字系统的语言则无需指定，de 到 de-DE 会按常规解析。non_translatable 条目则不受文字系统影响，始终会直接通过。
示例#
当一个按地区代码配置的引擎（en-US 到 fr-FR、de-DE、nb-NO）收到基础语言代码请求（fr、de、no）时：
fr目标会采用fr-FR的术语表、品牌语调和指令——它会被视为fr的默认项，而不是最后兜底选项，因为fr-FR是法语的 CLDR 默认地区。- 当源语言是
en时，也会匹配到en-US条目——因为匹配是双向的。 no目标不会采用nb-NO。no和nb属于不同的语言子标签，而不是一组地区变体；请使用nb作为目标。
在 API 中使用区域设置解析#
调用 localize endpoint 时，解析会自动完成。引擎会将请求中的 sourceLocale 和 targetLocale 与已存储的术语表、品牌语调、指令和模型配置进行匹配——无需额外参数。
