用途：为后端 API 与服务提供国际化方案，让机器可读的契约保持稳定，人类可读文本跟随请求或用户的语言环境。前端与移动端对应 i18n-frontend / i18n-mobile，接口契约参考 api-design。
主要能力与规则：错误使用机器可读 code（如 ORDER_NOT_FOUND），message 可选且已本地化或省略，由客户端翻译 code，不因语言改变 code。locale 解析优先级为：已认证用户资料 > 显式 query/header（lang、X-Locale）> Accept-Language > 默认值；不得仅以 geo-IP 作为来源。解析 Accept-Language 需处理 q 值并回退（pt-BR → pt → en）。API 中日期用 ISO-8601 或 epoch，日历格式化留给客户端，除非服务端生成 PDF/邮件。翻译目录随仓库版本化（locales/en.json、.ftl、.resx），不在功能中临时写 SQL 翻译。日志与指标保持英文/技术性稳定，不本地化运维日志。仅当服务端生成文本（邮件、PDF、推送）时才在服务端处理复数/ICU。
HTTP 与协议：示例头 Accept-Language: pt-BR, pt;q=0.8, en;q=0.5 与 X-Locale: pt-BR，需文档说明哪个头优先；响应体为本地化文本时返回 Content-Language；校验消息通过目录或 code（validation.email）。gRPC 将 locale 放在 metadata（x-locale）。
服务端翻译范围：邮件、短信、推送、面向人的 PDF/CSV、服务端报告在后台翻译；应用 JSON、API 错误 code、UI 标签交给客户端。若 API 仅供自家应用，优先 code + 客户端 i18n；若公开给第三方，则按请求 locale 返回 message。
各语言要点：Go 用 nicksnyder/go-i18n 或仓库现有库，按 locale 的 JSON/TOML bundle，Gin 中间件解析 locale 后 c.Set("locale", tag) 再 localizer.MustLocalize，用 golang.org/x/text/language 匹配，邮件模板传入 localizer 而非拼接。Rust 用 Fluent（fluent-templates / i18n-embed）或 rust-i18n，Axum 中通过 Extension/extractor 取 locale，.ftl 按语言分文件，用 unic-langid，避免无 locale 的 format! 日期。C#/ASP.NET Core 用 IStringLocalizer<T>/IViewLocalizer，.resx 或 JSON provider，RequestLocalizationOptions 配置默认与支持文化及 provider，ProblemDetails 的 type/code 稳定，持久化用 InvariantCulture。NestJS 用 nestjs-i18n，I18nContext/I18nService，i18n/ 下按 locale 的 JSON，解析顺序 header → query → cookie，异常过滤器映射 code → i18n.t('errors.' + code)，DTO 用 i18nValidationMessage。
邮件与异步任务：任务 payload 中持久化用户 locale，不用 worker 的 locale；模板用 react-email 配同 locale 字典并在 HTML 设 lang；退订/法律文本用账户语言。
反模式：按 pod 语言返回 err.Error()、翻译 code、在服务中拼接句子、无 locale 的 time.Format("02/01/2006")、handler 里巨型 map、只接受 lang=pt 而破坏 pt-BR。
完成标准：locale 按文档顺序解析；错误有稳定 code，人类文本走目录或客户端；目录入库，服务端生成散文处用 ICU/复数；任务与邮件持久化 locale；JSON API 日期用 ISO。
限制：资料未提供具体安装命令、版本要求、收费或性能数据，暂未提供。