企业官网建设流程全解析

new-api 俄语翻译术语表：本地化术语规范与多语言架构实现解读

【免费下载链接】new-apiA unified AI model hub for aggregation & distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api

导读：本文以 new-api 仓库中的 俄语翻译术语表（translation-glossary.ru.md） 为核心，系统梳理项目面向俄语（及多语言）本地化贡献者制定的核心术语标准、上下文变体翻译规则与语言特性约束，并结合仓库中真实的 i18n 实现（后端 go-i18n 消息包、中间件语言探测、前端 i18next）展开源码级佐证。读完本文，你将掌握 new-api 的术语一致性治理方法、俄语翻译的落地规范，以及翻译贡献者如何将术语表与运行时本地化机制衔接。

一、术语表的定位：让翻译"一致"而不只是"正确"

翻译技术文档时，"正确"不等于"一致"。同一个中文术语可能在不同页面、不同开发者口中出现多个俄语译法，最终导致用户在管理后台、计费报表、API 错误提示中看到互相矛盾的词汇。new-api 仓库在 docs/translation-glossary.ru.md（另有 英文主版 与 法语版）中为贡献者预先锁定了关键术语的标准译法，其核心目标写在文档开篇：

Данный раздел предоставляет стандартные переводы ключевой терминологии проекта на русский язык для обеспечения согласованности и точности переводов. （本节为项目关键术语提供标准俄语翻译，以确保翻译的一致性与准确性。）

术语表明确允许的三类翻译策略，与软件本地化（L10n）行业惯例一致：

• 保留 Emoji：如果原文中出现 Emoji，译文中允许保留；
• 保留纯技术术语：原文中的纯粹技术词汇不做强行意译；
• 保留通用英文技术词：在俄语技术圈已被广泛使用的英文术语（例如 API）直接沿用。

这一策略保证了译文既贴近俄语母语用户的阅读习惯，又不会为了"本土化"而牺牲技术准确性。从仓库的本地化实现看，这种"原文优先、宽松允许"的思路也体现在消息键的设计上：后端将所有可翻译字符串抽象为稳定的消息键（如common.invalid_params、token.invalid），键名本身即英文语义，翻译内容则完全交给各语言文件，见 i18n/keys.go。

二、本地化运行时架构：术语表服务的实际对象

在深入术语细节之前，先明确术语表与代码的对应关系。new-api 的国际化由独立的i18n包承载：

• 消息包初始化：i18n/i18n.go 中通过go-i18n库的i18n.NewBundle(language.Chinese)创建 bundle，并以go:embed方式把locales/*.yaml三个语言文件（zh-CN.yaml、zh-TW.yaml、en.yaml）嵌入二进制；
• 语言探测：中间件 middleware/i18n.go 在每个请求上执行detectLanguage，优先级为：用户设置（已登录时）→Accept-Language请求头 → 默认语言；
• 翻译入口：GetLangFromContext（i18n/i18n.go）完整实现了四层回退链：用户设置 → 按用户 ID 惰性加载 → 上下文语言 →Accept-Language头 → 默认英文；
• 消息键常量：i18n/keys.go 集中定义全部消息键，避免硬编码字符串；
• 业务侧调用：common.TranslateMessage在 common/gin.go 中作为钩子被i18n.T注入，业务代码只传键名与模板数据（如{{.Max}}、{{.Prefix}}）。

值得注意的边界：目前SupportedLanguages()返回的是zh-CN、zh-TW、en三种语言（i18n/i18n.go），normalizeLang也仅归一化中英文前缀。也就是说，俄语术语表当前属于"面向贡献者的翻译规范"，尚未进入运行时语言集合。这恰恰体现了术语表的先导作用：先定标准、再行翻译、最后接入locales/*.yaml与SupportedLanguages()即可完成语言上线。翻译贡献者提交俄语翻译时，应参照术语表新建locales/ru.yaml，并将ru纳入语言探测与支持列表——具体接入点在 i18n/i18n.go 的语言常量和 middleware/i18n.go 的探测逻辑。

三、核心概念术语表（Core Concepts）

以下为文档定义的最基础概念，贯穿所有界面与计费逻辑：

其中"倍率"一词在计价链路中语义关键。从源码看，倍率正是价格计算的乘数因子：model.Ratio与model.CompletionRatio分别构成"模型倍率"与"补全倍率"（model/pricing.go），而计费表达式引擎pkg/billingexpr在 compile.go 与 run.go 中把这些系数编译为可执行表达式——因此术语表强调计价上下文必须统一为 "Коэффициент"，正是为了避免"乘数"一词在计费语义中引发歧义。

四、模型相关术语（Model Related）

模型域是术语表最密集的部分，直接对应relay链路中的输入输出转换与计费参数：

"补全倍率"在实现中对应 OpenAI 生态的completion_ratio语义：当completion_ratio > 1时，输出 token 按ratio + (ratio - 1) * completion_ratio之类的方式叠加计费（具体公式见 relay/common/billing.go 与 common/quota_math.go）。术语表把"补全"锁定为 "Вывод"，恰好与"输出"共用一词，也与英文Completion = Output/Completion的等价标注形成对照——翻译时注意区分上下文即可，这正是下一节"上下文变体规则"要解决的问题。

五、用户管理与充值兑换术语

用户管理（User Management）

这三个角色在权限模型中有明确映射：RootUser是最初创建的超级管理员，AdminUser拥有系统管理权限，NormalUser为普通用户。仓库中权限判定分布在 service/authz 目录与 model/authz_role.go，术语表为这些角色在管理后台界面的俄语显示提供了统一口径。

充值兑换（Recharge & Redemption）

"兑换码"在实现中由 model/redemption.go 承载，支持批量生成、兑换额度、设置过期时间；其相关的错误提示键（如redemption.invalid、redemption.used、redemption.expired）集中在 i18n/locales/en.yaml。术语表选用 "Код купона"（优惠券代码）而非直译的"兑换代码"，是为了让俄语用户更直观理解其"兑换抵扣"的产品语义。

六、渠道管理与安全术语

渠道管理（Channel Management）

这组术语直接对应 model/channel.go 中Channel模型的关键字段：Priority（优先级）、Weight（权重，参与负载均衡选择，相关逻辑见 service/channel_select.go）、Proxy（代理地址，见 common/proxy_url.go）以及ModelMapping（请求体模型名替换，见 service/convert.go 与 relay/common/override.go）。

特别注意 "API ключ" 与 "Токен" 的区分：new-api 中用户的 API 访问凭证在管理界面称为"令牌"（Токен），而渠道侧接入上游供应商的凭证称为"API 密钥"（API ключ）。术语表刻意用两个不同俄语词区分这两个概念，避免俄语用户混淆"自己的访问凭证"与"上游服务商的密钥"——这在多语言界面中是一个非常实用的设计。

安全相关（Security Related）

两步验证在仓库中由 model/twofa.go、model/twofa_enrollment.go 与 common/totp.go 实现（TOTP 时间基一次性密码），登录流程要求输入 2FA 码的提示键为user.require_2fa（见 i18n/locales/en.yaml）。

七、上下文变体规则：一词多义的翻译决策树

术语表最重要的一节是"Контекстуальные варианты перевода"（上下文变体翻译），它解决了一词多义问题，给出了可执行的决策规则：

Промпт / Ввод（提示 / 输入）

• Промпт：用于与 LLM 交互的场景、用户界面文案、描述与模型互动的语境；
• Ввод：用于计费、技术文档、描述数据处理过程的语境；
• 规则：如果谈论的是用户体验和与 AI 的交互 → "Промпт"；如果谈论的是技术流程或计算 → "Ввод"。

Токен（Token）

• API 访问令牌（API Token）——用户调用网关时出示的凭证；
• 模型处理的文本单元（Text Token）——计费与 token 计数场景；
• 系统访问令牌（Access Token）——系统内部鉴权场景。

这三类 Token 在代码中都有对应物：前者是sk-开头的用户令牌（见 model/token.go 与 service/auth_token.go）；中者是 service/token_counter.go 统计的计费单元；后者是管理接口鉴权用的 Access Token。同一个英文词、三种俄语语境，翻译时必须按场景取舍。

Квота（额度）

• 用户的可用服务额度（标准译法）；
• 有时也译作 "Кредит"（信用额度）——术语表将其列为允许的变体。

八、俄语语言特性与翻译约束

术语表单独列出了俄语翻译必须注意的语言学特性，这些要求在代码的 i18n 框架中同样有迹可循：

• 复数形式（Множественные формы）：俄语名词复数分为_one、_few、_many、_other四类（如 1 个/2-4 个/5+ 个的变格），而go-i18n与 i18next 等框架均支持按复数类别选择译文，翻译时需为同一消息键提供多套复数形式；
• 格结尾（Падежные окончания）：技术术语在俄语中同样需要随格变化（主格、属格、与格等），译文应保证介词短语、复合名词的格一致；
• 语法性别（Грамматический род）：技术名词需要正确匹配性别——例如 "модель"（模型）为阴性，"канал"（渠道）为阳性，修饰语与形容词需随之变格。

九、标准化术语速查与贡献指南

术语表在结尾给出了四组"标准答案"，翻译时可直接套用：

• Вывод（Completion）：模型的输出内容；
• Коэффициент（Ratio）：用于计算价格的乘数因子；
• Код купона（Redemption Code）：替代"Код обмена"，更贴近产品语义；
• Поставщик（Provider/Vendor）：提供 API 或 AI 模型的组织或服务。

文档同时向贡献者开放了反馈渠道：

При обнаружении несогласованности в переводах терминологии или наличии лучших предложений по переводу, не стесняйтесь создавать Issue или Pull Request. （若发现术语翻译不一致，或对翻译有更好的建议，欢迎提交 Issue 或 Pull Request。）

结合 i18n/i18n.go 的实现，俄语本地化的完整落地路径可以归纳为四步：① 按本文术语表建立i18n/locales/ru.yaml并逐一翻译消息键；② 为俄语复数形式提供_one/_few/_many/_other多套译文；③ 在i18n包的语言常量与SupportedLanguages()中加入ru；④ 在前端（web/src基于 i18next，日期组件等已内置ru区域）同步接入俄语资源。这样，从术语规范到运行时渲染的整条本地化链路便完整贯通。

十、小结

new-api 的俄语翻译术语表是一份"先定标准、再行翻译"的本地化治理文档：它不仅给出了 5 大类 20 余个核心术语的标准俄语译法，还通过"重点提醒"（如 Коэффициент/Вывод/API ключ）主动消除歧义，通过"上下文变体规则"解决一词多义，通过"语言特性清单"约束复数、格与性别的正确性。配合仓库中 i18n 包、middleware/i18n.go 与 locales 文件的实际实现，这份术语表既是翻译贡献者的工作手册，也是理解 new-api 多语言架构的一把钥匙——任何语言的本地化贡献者，都可以参照 英文主版术语表 与 法语术语表 的同一套框架，为项目贡献高质量、高一致性的翻译。

【免费下载链接】new-apiA unified AI model hub for aggregation & distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api