AI 本地化工程 2026：游戏多语言管线的可验证落地
本地化是游戏工业化里少数几个成本完全线性、且每次迭代都要重做的环节。这篇讲的不是用大模型翻游戏，而是把本地化改造成一条可回归、可度量、可门禁的工程管线：七个阶段的输入输出契约、确定性代码该守住哪些硬约束、无参考评估模型怎么用来筛高价值子集，以及语音资产在包体与版权上的真实约束。
约 35 分钟阅读10,413 字2 次阅读博主
本地化是游戏工业化里少数几个成本完全线性、且每次迭代都要重做的环节。这篇讲的不是用大模型翻游戏，而是把本地化改造成一条可回归、可度量、可门禁的工程管线：七个阶段的输入输出契约、确定性代码该守住哪些硬约束、无参考评估模型怎么用来筛高价值子集，以及语音资产在包体与版权上的真实约束。
本地化是游戏工业化里少数几个「成本完全线性、且几乎每一次迭代都要重做一遍」的环节。它同时也是 AI 落地 ROI 最高、但工程约束最密集的场景之一——因为它同时要处理自然语言的不确定性、程序的可验证性，以及资产层的物理约束。
这篇讲的不是「用大模型翻游戏」，而是把本地化改造成一条可回归、可度量、可门禁的工程管线：每个阶段的输入输出契约是什么、哪些环节能交给模型、哪些环节必须由确定性代码守住、以及如何用真实指标证明这套改造值得做。
需要先划清边界。本文只讨论 AI 参与的游戏本地化工程实践（文本管线、术语一致性、质量评估、语音资产、运行时回归），不涉及引擎渲染管线的实现细节，也不讨论玩法系统架构；通用 Agent 编排范式同样不在讨论范围内——本地化管线的特殊性在于它的「AI 部分」被极度严格的格式契约夹在中间，而不是让模型自由行动。
先把成本结构摆清楚。本地化的成本不是一次性翻译费用，而是持续性成本：每个版本新增的文本、每个赛季的新活动、每次平衡性调整带来的 UI 字符串变更、每个 DLC 的新增剧情，全部要重新走一遍翻译—审校—排版—回归的循环。传统流程里，这条循环的节拍由语言供应商和译员的产能决定，通常以「周」为单位。
这带来两个具体后果：
第一，时序被语言卡死。 一个「全球同步上线」的项目，语言包交付周期往往比功能开发周期还长。中文团队做欧美市场，日语和东南亚语言还多一轮转写，欧美团队做日本市场则要处理敬语层级与汉字变体。每增加一种语言，成本不是线性叠加一个常数，而是叠加一条独立的流水线。
第二，质量不可控。 术语漂移、占位符破坏、UI 溢出、复数形式错误——这些缺陷不会在编译期暴露，只会在玩家屏幕上暴露。而它们恰恰是最难靠「增加人力」解决的，因为审校者面对的是几万条已经翻译过的字符串，注意力必然衰减。
于是 AI 在这里的切入点非常明确：不是替代译员，而是把「注意力」从全量扫描转移到高价值子集上。模型负责初译和风格统一，确定性代码负责格式守门，人负责少数机器判不准的语义和文化判断。
这也是本文的核心命题：本地化的 AI 化，本质是注意力经济学——用便宜的机器覆盖 80% 的确定性工作，把昂贵的人类注意力精确投放到剩下的 20% 上。
一条可工程化的游戏本地化管线，至少包含七个阶段。多数团队的问题不是「某个阶段做不好」，而是阶段之间的契约没定义，导致上游一个小改动在下游引发连锁人工排查。
| 阶段 | 输入 | 输出 | 谁负责 |
|---|---|---|---|
| S1 源串抽取 | 代码仓、资源文件 | 带上下文元数据的字符串条目 | 确定性脚本 |
| S2 上下文装配 | 字符串条目 + 截图 + 前后文 | 机器翻译可用的上下文包 | 确定性脚本 + 视觉模型 |
| S3 翻译与润色 | 上下文包 + 术语表 + 风格指南 | 候选译文 | LLM |
| S4 术语强制与占位符回填 | 候选译文 + 术语表 | 结构合法的译文 | 确定性代码 |
| S5 自动质检 | 译文 | 缺陷清单 + 质量分 | 规则引擎 + 评估模型 |
| S6 语音合成 | 台词 + 音色样本 | 音频资产 | TTS |
| S7 运行时回归 | 打包产物 | 溢出/缺字/不同步缺陷 | 无头测试 |
这个划分有一个关键的设计取向：S4 必须是确定性代码，而不是「再问模型一次」。原因是模型对格式约束的遵循是概率性的——即使你给了明确的指令，模型仍然会在长上下文中偶发地把 {player_name} 写成 {player.name}，或者丢掉一个换行符。这类缺陷不能靠采样概率解决，只能靠事后的硬校验和回填。
同样重要的是 S2 的「上下文装配」。游戏文本脱离上下文时是一串没有信息量的字符串——"Attack" 是技能名、是按钮、是提示还是台词？长度上限是多少？有没有复数形式？是否要保留玩家称呼？把这些元数据在抽取阶段就固化下来，是整条管线能不能自动化的前提。
术语表是本地化里最容易被低估、也最能体现工程水平的部分。
多数团队的做法是一份 Excel 术语表，交给译员阅读。人读得懂，但机器读不懂；或者交给模型当 prompt 的一部分，模型在几百条字符串的上下文里会逐渐忽略它。
更可靠的做法是把它拆成三个层次，并在管线里分别处理：
第一层：强约束（必须精确匹配）。 专有名词、UI 标签、角色名、技能名、法术名、UI 固定字符串。这类术语译错要人工改，模型出错要回退。做法是：翻译阶段把术语作为上下文提示注入，翻译后用精确匹配做强制回填——如果译文里该位置没有出现期望术语，直接判为缺陷，不用模型去「判断是不是同义改写」。
第二层：偏好（推荐用法）。 语气、敬语层级、代词选择、称谓方式。这类交给模型在润色阶段处理，因为它们是上下文相关的，规则化会误伤。
三层的分离很重要。 把强约束混进 prompt 让模型「注意点」，是很多团队本地化质量不稳的根因——模型没有「注意点」的语义，只有「概率上更可能遵守」的软信号。
一份可用的强约束术语表格式，大概长这样：
{
"version": "2026.10.29",
"entries": [
{
"source": "Arcane Surge",
"target": {"zh-Hans": "奥术涌动", "ja": "秘術の奔流"},
"scope": "skill_name",
"case_sensitive": true,
"forbid_alt": ["秘能激增", "奥能浪涌"]
}
]
}
注意 forbid_alt 这一列——它把「常见错误译法」显式列出来，效果通常好于只写正确译法，因为模型更容易被「不要这样写」这种信号引导。scope 则用于避免术语表在不该生效的地方生效（比如只在技能名语境生效的术语，不应出现在剧情对话里）。
术语漂移的检测可以在 S5 做：对每一对同源字符串，比较它们在同一语言下的译文相似度。如果两条语义相近的 UI 字符串译法差异过大，就标记出来。这本质上是一个「术语表完备性」的体检——如果你的术语表没覆盖到的地方，就是漂移最容易发生的地方。
如果只能修一个本地化 bug，修占位符破坏。
游戏文本里的机器可读片段至少有五类：变量插值（{player_name}、%d）、Unity 富文本标记（<color=#FF0000>、<b>）、BBCode 或 Markdown（**粗体**、[color]）、控制符（\n、\t）、以及图标占位（{icon:coin}）。
这些片段的正确处理方式是：在 S1 抽取时就把它们全部替换成不可翻译的哨兵标记，翻译完成后原样回填。看起来是常识，但实操中经常被做成「翻译后用正则检测，检测到就报错让人修」——这是把本可以自动修复的问题变成了人工负担。
关键实现细节有三个：
哨兵要唯一且不可能被模型「翻译」。 用 {ph_0}、{ph_1} 这样的编号形式，并且在整个语料范围内保证唯一。如果用有语义的名字（{player_name}），模型有概率认为「这是需要翻译的占位语义」而把它改成 玩家名称。
哨兵不能有语法暗示。 有些模型会认为 {ph_0} 看起来「不完整」，于是补全成 {ph_0} 后面加解释性文字。用不完整的占位反而降低了被改写的概率。
回填要区分「整块」和「内嵌」。 整块占位（一个 token 独占一段）直接映射；内嵌占位（你有 {count} 个 {item}）需要位置级替换，替换后要校验占位符集合与源串完全一致（集合相等 + 顺序一致 + 数量一致）。
一个可用的校验片段：
def placeholders(s: str) -> list[str]:
# 提取所有 {ph_N} 哨兵，按出现顺序
return re.findall(r"\{ph_\d+\}", s)
def verify_roundtrip(src: str, dst: str) -> list[str]:
a, b = placeholders(src), placeholders(dst)
if len(a) != len(b):
return [f"placeholder count {len(a)} != {len(b)}"]
if sorted(a) != sorted(b):
return ["placeholder set mismatch"]
return []
这个检查应当在 S4 结束和 S5 结束各跑一次。跑两次不亏：S4 跑一次抓模型改写，S5 跑一次抓回填代码本身的 bug——后者更隐蔽，且一旦发生就会污染整条语料。
翻译后的文本长度会变，这是必然的。不同语言的典型膨胀幅度差异很大，德语、俄语、芬兰语普遍偏长，日语和中文偏短。经验上，德语文本相比英语常出现 25%–35% 的膨胀，西班牙语、葡萄牙语在 15%–25% 区间，日语通常在 60%–80% 字符数（但视觉宽度未必更长，因为汉字是全角）。这些数字是经验区间，不同项目的实际分布要用你自己的数据校准，不要直接套用。
真正的问题是：UI 布局是在源语言上做好的，翻译后容器不会自己变长。按钮里的四字英文变成三倍长的德语，就可能被截断或溢出。
工程上有三种处理策略，按成本从低到高：
策略一：预算约束。 在 S1 抽取时给每条字符串打上 UI 容器尺寸标签（按钮/标签/提示/标题/多行正文），并在 S3 提示里带上目标语言的合理长度上限。这是最便宜的方案，但它依赖模型「自觉」控制长度，效果不稳定。
策略二：后置长度闸门。 用目标语言的经验膨胀系数做硬校验，超过预算就打回。这能在合入前拦住绝大多数溢出，但会误伤那些「本来就很长、必须允许」的字符串，所以预算需要分档而不是单一阈值。
策略三：运行时回归截图。 用无头模式跑一遍目标语言版本的 UI 截图，用像素级 diff 检测溢出、遮挡、截断。这是唯一能真正兜住布局问题的方法，代价是每次本地化更新都要跑一轮视觉测试。
对预算有限的团队，一个务实的组合是：策略二作为 CI 门禁，策略三只在版本发布前跑一次。对于按钮、标签这类短文本容器，再叠加一条规则——如果译文超过容器字符上限且找不到等价简写，标记为人工必看项。
一个值得记住的经验：溢出缺陷不应该在「翻译」这个维度上修。翻译者不知道你的容器有多宽，缩短它反而可能破坏语气。把「容器约束」作为一等公民传进翻译阶段，才是正确的顺序。
这是整个管线里 AI 含量最高、也最容易做成玄学的一环。
先说不能做什么：不能用「让 LLM 打分」当作唯一标准。LLM-as-judge 有已知偏差——位置偏差（同一个输出换个位置就换分）、长度偏好（更长往往得分更高）、以及自身模型的偏好（用 A 模型打分 B 模型的输出时，A 家族的输出天然占优）。这些偏差在单次评测里可能很小，但当你要用它做 CI 门禁、要求分数可回归时，它们会累积成噪声，让门禁变成随机开关。
正确的做法是三层评估，从确定性到概率性：
第一层：规则 lint（零误报）。 占位符集合一致、术语精确匹配、禁用词表（违禁词、种族/宗教敏感词）、控制符保留、HTML/XML 标签配对、URL 与占位格式。这一层应当做到零误报——它不评价语言质量，只评价结构合法性。
第二层：无参考翻译质量评估。 这是机器翻译评估的成熟路线。Unbabel 开源的 COMET 框架（GitHub Unbabel/COMET，Apache-2.0，2026-04-21 仍有提交，786 stars）就是一个基于预训练语言模型的翻译评估框架，它不需要参考译文就能打分。Unbabel 在 HuggingFace 上的 wmt22-cometkiwi-da 是专为「数据可用性受限」场景设计的版本——所谓 cometkiwi，kiwi 是新西兰俚语，寓意「这个基准很新鲜/来自最新评测」，da 表示它是在 WMT22 之后训练的数据分布上做的适配。截至实测，该模型在 HuggingFace 上 likes 113、近 30 天下载 3579 次，最后修改时间为 2025-04-07。
这类模型在工程上最大的价值是可离线、可批量、结果稳定——你可以对几万条译文跑一遍，成本远低于逐条调用商用 API。
第三层：LLM 评审（高价值子集）。 只对前两层标记为「可疑」或「高风险」的少量条目调用 LLM 做语义和文化判断。比如系统提示里直接给差异对照，让模型判断两种译法在目标语言的语境下哪个更自然、是否违反文化常识。
门禁阈值的设定有个实践细节：翻译记忆复用的字符串和全新翻译的字符串，应该用不同阈值。前者有历史质量基线，波动本身就是信号（说明源串或上下文变了）；后者没有基线，阈值应当更宽松，先用绝对分拦截明显糟糕的结果，而不是用相对波动卡死流程。
文本本地化做到位之后，语音是下一道坎，也是 AI 改变最彻底的一块。
技术路线已经收敛。 开源侧的生态相当完整：Kokoro-82M 是一个 82M 参数的 TTS 模型，在 HuggingFace 上 likes 7297、近 30 天下载 1080 万次，是当前最轻量的可用选项之一；F5-TTS 走的是非自回归 + 频谱生成路线，likes 1225、近 30 天下载 108 万；GPT-SoVITS 走少样本音色克隆路线，GitHub 上 64097 stars、MIT 协议、2026-10-19 仍有提交，官方描述是「1 分钟语音数据也能训出可用的 TTS 模型」；SeamlessM4T v2（Meta，GitHub facebookresearch/seamless_communication，11896 stars）是语音到语音翻译的端到端方案，HF 上 facebook/seamless-m4t-v2-large likes 1036、近 30 天下载 31 万。
值得注意的是项目的活跃度分化：coqui-ai/TTS 虽然有 46163 stars，但最后一次提交停在 2024-08-16；而 NVIDIA-NeMo/Speech 有 18640 stars、Apache-2.0、2026-10-29 当天还有提交——2026 年要做生产级 TTS 选型，这两个数据点的差别是决定性的。做技术选型时，star 数只是参考，最后一次提交时间才是项目是否还活着的一手证据。
音色克隆的合规问题必须前置。 用真人配音演员的声音训练克隆模型，涉及肖像权与声音权益，在部分司法辖区已有判例。这个问题不能等到「资产要用完再回头看」，应当在 S6 阶段就绑定授权记录：演员授权书范围（可用于哪些语言、哪些地区、是否允许用于 AI 模型训练、授权期限）、合成资产的再授权条款、以及模型权重的分发权。没有这些，克隆出来的音频是法律上不可交付的资产，哪怕技术上完美。
另外要注意口型同步（lip sync）是一条独立的工程线，和 TTS 不是一回事。语音生成解决了「说什么、什么音色」，lip sync 解决「嘴型对不对得上」。二者串联时会引入累积延迟和音画漂移，在动画类内容里肉眼可见。
包体是最容易被忽略的约束。 一款 30 分钟剧本的 RPG，全角色全语种配音的音频体积可以轻松超过数百 MB。对移动端和微信小游戏这类平台，这是不可接受的——微信小游戏官方文档明确限制「整个小游戏所有主包 + 分包大小不超过 30M，主包不超过 4M」。音频在这里不是「素材」，是「要么不装，要么按需下载」。
可行的策略是三选一或组合：按需下载 + 缓存（首次播放到某语言某章节时下载对应音频包）、远端流式播放（牺牲离线可用性换取包体）、分层降级（主线剧情用预装语音，支线用 TTS 或纯字幕）。第三种对独立游戏尤其现实：主线角色的关键台词值得占用配额，路人甲的几十句不值得。
包体约束一旦存在，多语言就不再只是文本问题。
字体是最容易爆炸的项。 完整的 CJK 字体动辄 10–20MB，如果主包需要同时支持中文、日文、韩文、繁体，字体子集化不是优化项而是必需项。做法是：先确定每种语言实际用到的字符集（从译文语料反向计算字形覆盖），再用字体子集化工具裁剪。子集化之后必须做缺字回退验证——因为字符集是从译文算出来的，但 UI 里可能有动态生成的玩家名、来自用户输入的昵称，这些字符不在子集里。生产环境需要准备兜底字体或运行时回退策略。
语言包要做成按需加载的分包。 结合微信小游戏的分包机制，主包只放当前语言 + 语言检测逻辑，其他语言包作为独立分包或远端资源。语言检测的优先级通常是：用户显式设置 > 系统语言 > 区域 IP > 默认语言。注意「用户显式设置」必须持久化，否则每次冷启动都可能被系统语言覆盖。
小游戏的更新机制带来额外约束。 微信小游戏的版本更新对资源是整体替换。语言包如果参与主包，每次改一个错别字都要重新提审——这会让「小步快跑地修本地化缺陷」变得不现实。工程上应当把语言包设计成可独立更新的资源，降低单次修改的审阅成本。
术语表、风格指南、源串抽取规则都应该版本化并可追溯。 本地化缺陷排查时，最常见的动作是「这个字符串在三个月前是怎么翻的、当时的术语表是什么」——没有版本化就只能靠猜。
「AI 提效 80%」这类话在游戏公司里很难通过评审，因为没人知道基线在哪。做本地化 AI 化，正确的第一步是在改造之前把基线量出来。
建议的最小指标集：
| 指标 | 定义 | 为什么重要 |
|---|---|---|
| 源串吞吐 | 单位时间完成并合入的本地化字符串条数 | 总体效率 |
| 单条后编辑时长 | 人工在候选译文上修改的平均耗时 | 真实人力成本，比吞吐更准 |
| 术语一致率 | 目标语言中术语表覆盖项被正确使用的比例 | 质量的硬指标 |
| 占位符破坏率 | 回填后占位符集合不一致的比例 | 最高频缺陷 |
| UI 溢出缺陷率 | 目标语言下溢出/截断的条目占比 | 玩家直接可见 |
| 缺陷逃逸率 | 本地化缺陷逃过自动质检进入发布的比例 | 质检层的有效性 |
| 语音资产单位成本 | 每千字音频的综合成本（算力 + 授权摊销） | 语音线的 ROI |
| 语言包体增量 | 每增加一种语言带来的包体与 CDN 成本 | 移动端的真实约束 |
采集方式要在改造前就搭好，否则事后补采的样本会被幸存者偏差污染——你只会记得那些后来被发现的问题。
不要只看 token 成本。 一个反直觉但重要的观察：LLM 翻译的 token 成本可能远低于人工译员的人力成本，但质量评审的成本反而可能上升——因为机器产出变多了，人要审的东西也变多了。如果你没有同时把「哪些可以跳过人工」这件事工程化（也就是上面说的注意力经济学），AI 本地化的净收益可能是负的。
这也是为什么本文反复强调 S4 和 S5 必须是确定性代码：它们决定了你的注意力是被节约下来，还是被转移到新的地方。
按在项目里出现的频率排序，每条都附上防御动作：
术语漂移。 同一个词在几百条字符串里出现不同译法。防御：三层术语表 + 译后精确回填 + 相似度漂移检测。
占位符破坏。 防御：哨兵替换 + 位置级回填 + 集合校验（跑两次）。
复数与形态错误。 英文的 {count} item(s) 模式在英语里能糊弄过去，德语、俄语、阿拉伯语有真实的复数形态和格变化，需要按数量选择不同词形。防御：这类字符串不要交给通用模型，用带数量形态表的专用模板处理。
RTL 布局。 阿拉伯语、希伯来语从右向左，标点、图标方向、数字与单位顺序都需要处理。防御：这一层属于引擎/UI 工程范畴，但翻译管线必须把 RTL 语言单独分桶，因为它的质检规则和 LTR 不同。
文本长度溢出。 防御：预算约束 + 长度闸门 + 发布前视觉回归。
字体缺字。 防御：子集化 + 动态文本兜底 + 缺字扫描（把渲染结果里的豆腐块识别出来）。
文化禁忌与幽默失效。 押韵、双关、谐音梗在跨语言里基本失效，直译会变得尴尬。防御：这类字符串打上标记强制人工审校，模型只能提供直译参考不能直接合入。
假本地化。 漏翻的字符串直接透传源语言，在玩家眼里是「游戏没做完」。防御：S5 规则层强制检测「与源串完全相同但语言不同」的条目。
语音与字幕不同步。 防御：语音生成与字幕生成共用同一份带时间戳的台词中间格式，时间戳只在一处产生。
数据出境与合规。 未发布的剧情、角色设定、内部术语表发给境外 API，可能触及商业秘密与监管要求。防御：管线里显式标注每个字符串的敏感等级；敏感等级高的走本地部署模型或人工通道。
阶段 0（第 1–2 周）：建基线，不动流程。 把 S1 抽取脚本写出来——即使它只是从 CSV/JSON 里把字符串读出来。同时把第九节的指标采集搭起来。没有基线，后面所有「提效 X%」都是自说自话。
阶段 1（第 3–6 周）：引入 LLM，但守住结构。 上 S2/S3/S4。此时模型的输出不直接进版本，而是进一个审校工作台。目标是测出真实的后编辑时长变化，以及最常见的模型破坏模式有哪些。这个阶段的价值不在于省人力，而在于把「模型会犯什么错」变成可枚举的清单——这份清单决定了你后面的确定性代码要写什么。
阶段 2（第 7–10 周）：加上自动质检与门禁。 上 S5 的规则层和无参考评估，CI 里挂上。先只报告不阻断，跑两周看误报率，误报率降到可接受再开启阻断。直接上线阻断是新手最常犯的错——误报会迅速让团队养成绕过门禁的习惯，比没有门禁更糟。
阶段 3（第 11–13 周）：上语音与运行时回归。 如果前面三步的指标是正的，语音线的投入才有依据。同时把视觉回归测试接进发布流程，这是溢出和缺字缺陷的唯一真兜底。
诚实标注几个业内尚未有可靠公开数据的点，避免把推测当结论：
AI 本地化对留存率的实际影响。 厂商侧宣称的数据存在明显的利益相关性——例如某本地化服务商公开表示「AI 驱动的游戏本地化交付速度比传统流程快 40%」，这是厂商自述的流程效率数字，不等于玩家侧的留存提升，且未见公开的、对照实验设计说明。
不同语言的目标市场，AI 本地化的边际收益差异。 公开分析普遍认为 2026 年下半年会出现一批中小独立游戏以 5–8 种语言同步上线的案例，但截至本文写作时，未见公开的、可查证的样本数据表明这些多语言版本相对于单语言版本的营收差异幅度。
玩家对「AI 翻译」的容忍度。 社区讨论中存在明显的分歧，一派认为标注清楚即可接受，另一派认为低质量翻译损害品牌，但未见覆盖多个地区、多个品类的系统性调研。
AI 语音在角色扮演类游戏中的接受度。 目前没有公开数据显示玩家对合成音色的耐受阈值，也没有可靠的行业基准说明「多少比例的对白使用合成语音会引发负面反馈」。
这些空白恰恰是中小团队的机会窗口：先做的人没有公开的对照数据可抄，意味着更早建立自己团队内部的度量基线反而更有价值。
游戏本地化的 AI 化本质是注意力经济学——用确定性代码守住格式与术语的硬约束、用无参考评估模型筛出高价值子集、把人只投放到机器判不准的语义与文化判断上，并配一套从翻译记忆复用到 UI 溢出回归的完整指标体系，才算把 AI 真正接进了一条可回归、可门禁、可证明 ROI 的工程管线。
Unbabel/COMET, Apache-2.0, https://github.com/Unbabel/COMETUnbabel/wmt22-cometkiwi-da on Hugging Face, https://huggingface.co/Unbabel/wmt22-cometkiwi-damicrosoft/LLMLingua, MIT, https://github.com/microsoft/LLMLinguafacebookresearch/seamless_communication, https://github.com/facebookresearch/seamless_communicationfacebook/seamless-m4t-v2-large on Hugging Face, https://huggingface.co/facebook/seamless-m4t-v2-largeopenai/whisper, MIT, https://github.com/openai/whisperopenai/whisper-large-v3 on Hugging Face, https://huggingface.co/openai/whisper-large-v3RVC-Boss/GPT-SoVITS, MIT, https://github.com/RVC-Boss/GPT-SoVITSNVIDIA-NeMo/Speech, Apache-2.0, https://github.com/NVIDIA-NeMo/Speechcoqui-ai/TTS, MPL-2.0, https://github.com/coqui-ai/TTSargosopentech/argos-translate, MIT, https://github.com/argosopentech/argos-translateHelsinki-NLP/Opus-MT, MIT, https://github.com/Helsinki-NLP/Opus-MTgodotengine/godot, https://github.com/godotengine/godotneedle-mirror/com.unity.localization, https://github.com/needle-mirror/com.unity.localizationConversation
0 条