Go go-i18n 多个语言偏好参数怎样决定匹配结果

Go go-i18n 的 NewLocalizer(bundle, langs...) 会逐个解析语言偏好字符串，再按参数顺序拼接得到的语言标签。一个Accept-Language字符串内部的q值参与该字符串的偏好排序，不会把所有参数的q值合成一张全局排行榜。之后，Bundle支持的语言集合参与最佳匹配；找到语言与找到某条消息是两个不同问题。

项目官方地址：https://github.com/nicksnyder/go-i18n

建立语言匹配与消息回退两个观察基线

排查“传了两个语言却没显示预期翻译”时，先记录两个基线：一是相同消息在各语言中都存在时，偏好如何影响选择；二是选中语言缺少消息时，最终使用什么文本、返回哪个标签、有没有错误。只比较屏幕上的一句话，无法区分语言选择和消息缺失。

本文使用英语默认语言、法语和德语，设置完整翻译与故意缺少翻译的消息，展示可观察入口。示例没有实际运行，表中的结果是依据实现推导的预期；性能耗时、分配和命中率没有实测数据。

解释多个参数与q值的作用范围

例如把用户主动选择的 "fr" 放在第一个参数，把浏览器头部 "en;q=1,de;q=0.8" 放在后一个参数，是在表达来源优先级。实现分别解析两个字符串，再把法语标签放在后面那组标签之前。后一个字符串中的q=1不会跨越参数边界，自动把它提升到所有来源的最前面。

如果只传一个 "fr;q=0.2,de;q=0.9"，则两个偏好在同一个Accept-Language值里，解析器按质量权重组织偏好。零权重项会被底层Accept-Language解析器排除。不要在多个参数之间比较q值大小，推断出源码没有执行的全局排序。

标签顺序仍不是简单的字符串精确查表。底层语言匹配器考虑支持语言和匹配程度；较早的近似匹配与较后的精确匹配可能存在取舍。尤其区域、脚本变体并存时，不能把“第一个参数”写成无条件必胜的规则。

编写可观察匹配标签的完整示例

将下面代码放入配置好go-i18n v2与 golang.org/x/text/language 依赖的Go模块。固定项目使用的模块版本，并让翻译资源在启动阶段准备完成。

package main

import (
    "fmt"
    "github.com/nicksnyder/go-i18n/v2/i18n"
    "golang.org/x/text/language"
)

func main() {
    bundle := i18n.NewBundle(language.English)
    // 在启动阶段确定支持语言；法语故意不包含receipt消息。
    bundle.MustAddMessages(language.English,
        &i18n.Message{ID: "title", Other: "Workspace"},
        &i18n.Message{ID: "receipt", Other: "Receipt"})
    bundle.MustAddMessages(language.French,
        &i18n.Message{ID: "title", Other: "Espace"})
    bundle.MustAddMessages(language.German,
        &i18n.Message{ID: "title", Other: "Bereich"},
        &i18n.Message{ID: "receipt", Other: "Beleg"})

    cases := []struct {
        name string
        langs []string
        id string
    }{
        {"显式偏好在前", []string{"fr", "en;q=1,de;q=0.8"}, "title"},
        {"单个头部按权重", []string{"fr;q=0.2,de;q=0.9"}, "title"},
        {"首选语言缺少消息", []string{"fr", "de"}, "receipt"},
    }
    for _, item := range cases {
        localizer := i18n.NewLocalizer(bundle, item.langs...)
        // 同时观察文本、实际消息语言与错误，不只打印文本。
        text, tag, err := localizer.LocalizeWithTag(&i18n.LocalizeConfig{
            MessageID: item.id,
        })
        fmt.Printf("%s: message=%q tag=%s err=%v\n",
            item.name, text, tag, err)
    }
}

代码通过 LocalizeWithTag 同时读取三个返回值。tag说明实际返回消息所属的语言；发生回退时，它不一定就是第一次匹配到但缺少消息的语言。文本不为空与error为nil也不是同一件事。

比较预期结果并安排测量方法

第三行是最容易被误解的地方。当前实现先进行语言匹配，再查该语言的消息；缺失时检查Bundle默认语言及配置中的默认消息，而不是为每个MessageID依次尝试全部langs。因此，德语明明有receipt，也不代表这一调用会返回德语。

若要评估接入成本，可将构建Bundle、创建Localizer和执行本地化分开测量，保持翻译资源规模、偏好数量与消息ID一致；分别记录 ns/op、B/op 和 allocs/op。功能观测可记录消息缺失错误数和默认语言回退数，不能把它们与耗时混成一个“命中率提升”结论。

本文没有执行基准，所以没有前后加速比例。若业务准备调整偏好来源顺序，应先写清楚语言政策，观察返回tag和错误的变化，再决定是否采用；改变来源顺序首先是产品行为变化，不是性能优化。

处理区域变体与回退边界

同一基础语言有多个区域变体时，Bundle中的支持标签及其加入顺序可能影响最佳匹配结果。默认语言、加载资源的顺序以及底层语言匹配器版本都应保持可解释；不能用一个只含en和fr的小例子，推断所有en-US、en-GB或中文脚本变体组合。

无效偏好字符串在当前go-i18n解析实现中会被跳过。产品若需要拒绝错误的用户设置，应在业务入口单独解析并反馈，而不是期待NewLocalizer返回一个不存在的解析error参数。

页面可以选择在记录缺失错误的同时显示回退文本，但需要明确处理政策。直接忽略error会掩盖翻译不完整；直接使用MustLocalize又可能把允许回退的请求变成panic。面向请求处理的代码通常更适合显式处理返回值。

没有传语言参数会怎样？

匹配仍依赖Bundle的支持语言及默认配置。业务若要求固定缺省语言，应明确配置默认语言，而不是依赖调用处碰巧遗漏参数。

传用户设置还是浏览器头部在前？

由产品政策决定。用户主动选择通常应有清楚的优先级，但匹配还受到支持语言与匹配程度影响；不要把库调用参数顺序当成完整的产品语言规则。

想按每条消息尝试所有偏好怎么办？

这属于不同的回退策略，需要业务显式实现并定义混合语言页面是否可接受。不要把现有langs列表误当成逐消息翻译搜索清单。

技术依据：go-i18n语言偏好与消息回退实现、Go语言偏好解析文档、go-i18n接口文档。