一个小团队请你把中文应用界面整理成英文，交付的文件看起来语句通顺，上线后却出现用户名消失、按钮挤成两行、删除操作被译成取消等问题。这类服务的难点不只是语言转换，还包括键名、变量、语境和界面长度。

本文给出 AI 辅助界面文案本地化 的小范围交付流程：以四条虚构界面文案为例，准备上下文、让 AI 起草、保留占位符，再用离线脚本检查结构。适合已经具备相应语言审核能力、希望提供轻量文案服务的人；不会目标语言时，不能只凭模型输出承接专业翻译保证。

示例没有真实客户、订单或收益，未进行模型付费调用。最终成果是一套可交给开发者复核的 JSON 文件、术语表和问题记录，不包含直接发布到生产环境的操作。

一、先把服务范围限定下来

本例只处理 UTF-8 JSON 对象中的简单字符串，采用 i18next 默认的 {{name}} 形式插值。约定只支持由字母或下划线开头、包含字母数字下划线的变量名，不处理 HTML、嵌套引用、复数后缀、日期货币格式或带格式参数的插值。

i18next 官方文档支持的能力比这个练习更多，例如嵌套结构、复数和格式化。本例检查器是有限范围的交付辅助工具，不是完整的 i18next 校验器。一旦客户文件超出约定，先调整范围和测试，不把不认识的语法交给 AI 猜。

接单前确认源语言、目标地区、语气、软件用途、字符串数量、修改轮次和技术负责人。英文也存在不同地区的拼写与表达习惯，不能只写一个模糊的“翻译成英文”就开始计价。

需要另外列出不包含的事项：法律条款翻译、支付与退款规则审核、应用代码集成、所有设备的完整测试，以及未经确认的新增业务文案。范围清楚才能估算工作量；不要用“AI 一键处理”掩盖人工审校和界面返工。

二、拿到上下文，而不只拿到一列句子

让客户提供待处理键名、原文、所在界面、触发条件、读者动作和可用空间。允许提供截图时，应先隐藏个人资料与访问令牌。没有截图也可用简单线框说明按钮位置，不必为了四句话索取整个代码仓库。

本例建立 zh.json：

{
  "welcome": "欢迎，{{name}}",
  "save": "保存草稿",
  "delete_confirm": "确定删除“{{title}}”吗？",
  "retry": "连接失败，请重试"
}

再写上下文：welcome 位于用户首页；save 只保存未发布草稿；delete_confirm 在永久删除前询问；retry 表示网络请求失败后可重试。删除确认是否真的永久，是本例的虚构业务设定，真实项目要向产品负责人核对，不能由翻译者自行补充。

不要翻译键名，也不要把 {{name}} 译成中文“姓名”。键名是程序查找文案的接口，变量由运行时填入。即使替换后读起来更自然，只要程序无法找到原变量，交付就不合格。

三、先建一份短术语表

本例约定 draft 为草稿，save 为保存，delete 为删除，retry 为重试。这里的 cancel 不等于 delete，submit 不等于 save。把这些区别写进术语表，能减少同一批字符串里混用动作含义的问题。

还要确认称呼、标点和语气。比如错误提示是否直接说明问题，按钮是否用动作短语，确认弹窗是否重复对象名称。不要为了“更有营销感”把一个清晰的保存按钮改成与操作含义不一致的宣传语。

术语表应包含源词、目标词、适用语境和不能混用的词。遇到无法判断的内容写进问题单：谁来确认，确认前采用什么临时处理。没有回答时可以先标待审，但不能把待审稿当成可直接上线版本。

知行之外 · mywwx.com

四、让 AI 起草值，同时约束输出边界

使用客户允许的 AI 工具，在空白对话中只放这批虚构字符串、术语表和上下文。真实项目是否可以上传材料，需要按客户和组织规则确认。不要把 API 密钥、客户名单或完整私有配置当作翻译上下文。

下面是可改写的起草任务：

请把以下虚构中文界面字符串起草为简洁自然的英文。
只修改 JSON 的值，不增删或翻译键名。
保留每个 {{变量}} 的名称、括号和出现次数。
不要添加 HTML、转义插值、复数规则或其他框架语法。
save 是保存未发布草稿，不是发布；delete 是删除，不是取消。
先输出合法 JSON，再单独列出需要产品确认的语境问题。
不确定的业务事实不要自行补充，不承诺已经经过真人语言审校。

将 JSON 结果单独保存为 en.json，把解释和问题另存文件，不能把模型的说明文字一起放进配置。以下只是人工编写的示例目标稿，不是某模型实际输出：

{
  "welcome": "Welcome, {{name}}",
  "save": "Save draft",
  "delete_confirm": "Delete \"{{title}}\"?",
  "retry": "Connection failed. Try again."
}

注意删除确认里需要符合 JSON 的引号转义。模型输出看起来像对象不代表能被解析，尤其是智能引号、尾部逗号和附带注释。不要通过删除异常内容直到“能打开”来处理，先确认是否改变了业务含义。

五、先运行结构检查，再做语言审核

电脑需有 Python 3。把两个 JSON 和下面的 check_locale.py 放在同一空目录，执行 python --version 后运行 python check_locale.py。脚本只读取本地文件，不调用 AI、不修改源文件。

import json
import re
from collections import Counter
from pathlib import Path

token = re.compile(r"\{\{([A-Za-z_][A-Za-z0-9_]*)\}\}")

def unique_object(pairs):
    result = {}
    for key, value in pairs:
        if key in result:
            raise ValueError("JSON 含重复键：" + key)
        result[key] = value
    return result

def load(name):
    value = json.loads(Path(name).read_text(encoding="utf-8-sig"),
                       object_pairs_hook=unique_object)
    if not isinstance(value, dict) or not value:
        raise ValueError("需要非空 JSON 对象")
    if any(not isinstance(v, str) for v in value.values()):
        raise ValueError("本例仅支持字符串值")
    return value

def variables(text):
    remainder = token.sub("", text)
    if any(mark in remainder for mark in ("{", "}", "<", ">", "$t(")):
        raise ValueError("遇到超出练习范围的插值或标记")
    return Counter(token.findall(text))

def validate(source, target):
    if source.keys() != target.keys():
        raise ValueError("源文件与目标文件键名不同")
    for key in source:
        if not target[key].strip():
            raise ValueError("空译文：" + key)
        if variables(source[key]) != variables(target[key]):
            raise ValueError("变量名称或次数变化：" + key)

if __name__ == "__main__":
    source, target = load("zh.json"), load("en.json")
    validate(source, target)
    print("结构检查通过；语言、业务与界面仍需人工验收")

这里比较变量出现次数，而不只是比较变量集合。如果一条句子本来两次显示对象名，译文只保留一次，开发者可能需要单独确认；脚本不会静默把这种变化放行。重复键也会被拒绝，避免解析器只保留最后一项而掩盖丢失。

六、用几种错误稿验证检查器

先保存好正确的 en.json 副本，再做教学测试：删除 save 键，应报键名不同；把 {{name}} 改为 {{user}}，应报变量变化；把某个值清空，应报空译文；在同一对象里写两次 retry，应在读取时拒绝。

测试结束恢复正确文件再运行。本文自编脚本已离线检查这些异常以及变量次数变化，但没有在实际 i18next 应用中运行渲染，也没有进行真实客户验收。结构通过只说明约定内的文件契约没有被破坏，不说明英文表达正确。

语言审核需要逐条对照上下文：保存有没有被改成发布，重试是否暗示一定成功，删除确认有没有遗漏对象，错误提示有没有责怪用户。不能让同一个 AI 对自己的稿件说一句“没问题”就代替具备能力的人工审核。

七、长度检查要落到真实界面

W3C 的国际化资料说明，翻译后文本长度经常变化，尤其是紧凑的短字符串。字符数相同也不代表占用宽度相同。不要承诺“中文四个字，英文也控制四个字符”，这会迫使译文牺牲含义。

将目标稿交给开发者放进测试环境，查看窄屏、较大字号和长变量值。例如用较长的虚构用户名替换 {{name}}，检查欢迎语能否换行；用较长标题替换 {{title}}，查看确认按钮是否仍能操作。变量本身长度也会影响布局，不能只测短词。

发现按钮太窄时，先讨论布局是否可以伸缩或换行，再考虑保持含义的短译文。不要靠修改全站字体大小来掩盖单个字符串的问题，也不把文本裁成省略号后假定关键操作语义仍然完整。

知行之外 · mywwx.com

八、交付、报价和后续修改怎样约定

交付目录可包含源稿、目标稿、术语表、问题单、检查脚本及检查记录。另写一页说明：目标地区、采用的语气、占位符规则、尚未覆盖的框架特性、需要开发者测试的界面。版本号按本次交付约定命名，不覆盖客户原文件。

报价拆成上下文整理、AI 起草、人工语言审校、技术检查、界面复核和修改轮次。短字符串虽然字少，但语境确认可能更费时，不能只按模型生成时间判断成本。模型费用、软件订阅与人工复核属于不同成本，不虚构市场统一报价或预期收入。

可以先用四到十条脱敏样稿让客户确认术语与风格，再扩大范围。展示作品时使用自己的虚构界面和文字，不擅自公开客户后台。争议最多的不是有没有翻译，而是“可读稿”和“可直接上线稿”的边界，最好在制作前讲清。

后续源文新增字段或改变变量时，要重新比较两个文件；不把上次通过的报告沿用到新版本。遇到复数、HTML 或嵌套语法，暂停当前简单检查器的结论，由开发者提供对应框架规则，再补测试后处理。

官方资料

• i18next：插值变量语法与默认转义
• i18next：JSON 格式、复数与其他扩展语法
• W3C：翻译中的文本长度变化与布局考虑