JSON 翻译器#

JsonTranslate，一款专为开发者和内容创作者设计的多语言 JSON 翻译工具，支持 Google Translate、Azure 和 DeepL(X) 翻译 API，助力项目国际化和本地化。无论你是在开发多语言网站、应用程序还是处理多语言数据集，JsonTranslate 都能提供简便的解决方案，轻松将 JSON 文件中的内容翻译为多种目标语言。

翻译模式说明#

全局翻译#

全局翻译会递归遍历整个 JSON 数据结构，对所有字符串类型的值进行翻译，同时保持原始 JSON 的层级与结构不变。

适用场景：

• 需要对整份 JSON 文件中的文本内容进行全面翻译
• 无需复杂配置，一键翻译所有内容

指定节点#

通过 JSONPath 表达式，精准定位一个或多个节点，仅翻译这些节点中的字符串内容。支持多个路径，用英文逗号分隔。

适用场景：

• JSON 数据具有清晰的层级结构，仅需翻译特定部分
• 针对大型 JSON 文件，缩小翻译范围提高效率

指定键名#

在此模式下，你可以指定特定的键名进行翻译。支持两种输入方式：

• 简单模式：直接在输入框中通过逗号（中英文均可）分隔需要翻译的键名，程序会将这些键的内容进行翻译。
• 高级模式：通过键名映射组件设置输入键与输出键的对应关系，翻译结果将写入新字段中，保留原字段不变。

适用场景：

• 仅需翻译特定字段，例如 title、description 等
• 需要将翻译结果输出到不同字段，避免覆盖原数据

注意事项：

• 键名区分大小写
• 若 JSON 中包含数组，避免使用纯数字作为键名，以防被识别为索引
• 输入键与输出键数量必须一致

选择性翻译#

此模式适用于扁平结构的 JSON 数据，可指定起始节点和需要翻译的字段名称。系统会从指定节点开始，查找所有对象中的目标字段并进行翻译。

配置项：

• 起始键：(可选) 指定从哪个键开始查找，适用于键顺序有意义的场景
• 待翻译字段：要翻译的具体字段名称，多个字段用逗号分隔

适用场景：

• 只需翻译扁平化结构中指定字段，如日志或错误信息的"message"字段
• JSON 文件结构简单，字段重复出现但需部分处理

i18n 模式#

i18n 模式专为多语言场景设计，能在原有 JSON 结构中聚合多语言的字段内容。适合用于构建多语言网站或应用的翻译文件，或管理统一结构下的多语言配置。

工作原理#

• 使用选择的源语言作为源字段，比如源语言为 zh，源字段就是 zh。当源语言为 auto 时，源字段则为默认的 en。
• 遍历 JSON 中所有包含源语言字段的对象，为每个对象新增目标语言字段（与源语言字段同级）。
• 若目标语言字段已存在，则跳过翻译，避免覆盖已有内容。
• 当同时启用 i18n 模式和多语言模式时，系统将创建一个包含源语言和所有目标语言的统一 JSON 结构，这对国际化项目特别有用。

示例#

{
  "title": {
    "en": "Settings"
  }
}

目标语言设定为 zh、fr，翻译结果：

{
  "title": {
    "en": "Settings",
    "zh": "设置",
    "fr": "Paramètres"
  }
}

翻译 API#

本工具集成了 5 种翻译 API 和 6 种主流大语言模型（LLM）接口，用户可根据需求选择合适的翻译方式：

翻译 API 对比#

• DeepL：适用于长篇文本，翻译更加流畅自然，但不支持网页端 API，需本地或服务器代理调用。
• Google Translate：翻译质量稳定，适用于短句、界面文本，支持网页端调用。
• Azure Translate：支持语言最多，适合多语言翻译需求。
• GTX API/Web：免费翻译选项，适合轻量级使用，但稳定性和调用频率有限。例如，mrfragger 在翻译一个约 200 万字符的字幕文件（约 2MB）时，仅执行两次翻译即触发了 GTX API 限制。

如果对翻译速度和质量有更高要求，可自行申请 API Key：Google Translate、Azure Translate、DeepL Translate。申请流程参考相关的接口申请教程。

LLM 翻译（AI 大模型）#

除传统翻译 API 外，本工具还支持调用多种 LLM 进行智能翻译，包括：DeepSeek、OpenAI、Azure OpenAI、Siliconflow、Groq，以及可自由配置的 Custom LLM。

• 适用场景：适合处理语言理解要求较高的内容，如文学作品、技术文档、多语种资料等。
• 高度可定制：支持配置系统提示词（System Prompt）与用户提示词（User Prompt），可灵活控制翻译风格、术语偏好等，满足多样化的翻译需求。
• LLM 模型：一般情况下填写所选接口提供的模型名称；若使用 Azure OpenAI，则需填写对应的部署名称。
• 温度参数（temperature）：用于控制翻译结果的创造性与稳定性。数值越高，生成内容越具多样性和创造性，但可能降低准确性；数值越低，输出更稳定、一致，适合正式或技术性较强的场景。

本地模型连接说明#

对于希望在本地部署大模型的用户（如 Ollama、LM Studio），可通过以下方式完成本工具的连接配置。为获得更优的翻译质量，推荐在自定义模型中使用 qwen2.5-14b-instruct 或性能更高的模型。

默认接口地址示例#

• Ollama：

http://127.0.0.1:11434/v1/chat/completions

• LM Studio：

http://localhost:61234/v1/chat/completions

跨域访问配置方法（CORS）#

如果在浏览器中调用本地部署的模型时出现连接失败，可能是由于浏览器的跨域策略导致。解决方式如下：

• Ollama：需通过如下命令启动服务以允许所有来源访问：

OLLAMA_ORIGINS="*" ollama serve

• LM Studio：

  1. 打开软件左侧菜单，点击「Developer」图标；
  2. 进入本地服务器设置页面，点击顶部「Settings」；
  3. 勾选“Enable CORS”复选框。

  

完成以上配置后，本工具即可顺利调用你的本地 LLM 模型。（特别感谢 mrfragger 分享配置经验）

语言支持#

本工具支持 50 多种语言之间的互译，覆盖广泛的欧洲、亚洲及部分非洲语言，适用于各类跨语言内容处理场景。支持的语言包括：英语、中文、繁体中文、葡萄牙语、意大利语、德语、俄语、西班牙语、法语、日语、韩语、阿拉伯语、土耳其语、波兰语、乌克兰语、荷兰语、希腊语、匈牙利语、瑞典语、丹麦语、芬兰语、捷克语、斯洛伐克语、保加利亚语、斯洛文尼亚语、立陶宛语、拉脱维亚语、罗马尼亚语、爱沙尼亚语、印尼语、马来语、印地语、孟加拉语、越南语、挪威语、希伯来语、泰语、菲律宾语（塔加拉语）、乌兹别克语、吉尔吉斯语、土库曼语、哈萨克语、博杰普尔语、卡纳达语、阿姆哈拉语、古吉拉特语、爪哇语、波斯语、泰米尔语、斯瓦希里语、豪萨语、泰卢固语和马拉地语等。

API 具体支持语言详见各服务的官方文档：

• DeepL 支持的语言

• Google Translate 支持的语言

• Azure Translator 支持的语言

功能说明#

映射翻译#

在使用指定键名模式时，你可以通过结果区的切换按钮，在单一键名模式和映射翻译模式之间切换。单一键名模式下，翻译的输入输出使用相同节点，而映射翻译模式则涉及不同节点的翻译。例如，节点 A 的值将翻译至节点 B，节点 C 的值翻译至节点 D。

翻译缓存#

本工具引入可选的本地翻译缓存，提高翻译效率并降低资源消耗：

• 缓存规则：每段翻译结果将以 源文本_目标语言_源语言_翻译 API_模型设置 作为唯一 key 进行存储。
• 缓存命中条件：只有完全匹配相同参数的情况下，才会使用本地缓存结果，确保准确性。
• 缓存作用：避免重复翻译，减少 API 调用次数，提高翻译速度。

如果不想使用缓存，可取消勾选“使用翻译缓存”，或在 API 设置中点击“清除翻译缓存”。

多语言翻译#

支持将同一个文件一次性翻译为多种语言，特别适合需要国际化的视频内容：

• 例如：将英文文件同时翻译为中文、日语、德语、法语，方便全球用户使用。
• 支持 50 种主流语言，并将持续扩展。

导出与导入设置#

支持一键导入与导出当前设置，便于在更换设备或切换至自有域名时快速迁移数据。

请注意：

• 导出的文件将包含所有配置信息，包括 API 密钥等敏感数据；
• 请妥善保管导出的文件，避免泄露或误用；
• 导入操作会覆盖现有设置，执行前请确认无误。

常见问题#

为什么翻译结果为空、仅显示原文，或显示为 null？#

出现这种情况，可能有以下几种原因：

• API 密钥（API Key）或相关设置不正确；
• 账户的可用额度（Credits/Token）已用尽；
• 翻译速率设置过高，或接口本身暂时不太稳定。

你可按 F12 打开浏览器开发者工具，切换至 “网络”（Network）标签页，检查 API 响应（Response）的具体报错信息。

如果只是部分内容未能成功翻译，尝试再次点击“翻译”按钮即可。在启用了翻译缓存的情况下，系统会跳过已翻译的内容，避免重复扣费或重复请求。

为什么要用第三方接口访问 DeepL？#

因为 DeepL 的官方服务不允许直接从网页上调用，所以我们通过一个“中转通道”来帮你把请求发出去。

这个中转接口只是用来传输数据，不会收集你的任何信息，你可以放心使用。如果你对稳定性有更高要求，也可以自己搭建这个通道。

我的 API Key 会被保存吗？#

不会的！你的 API Key 和其他设置都只保存在你自己的浏览器里，我们不会上传或记录任何信息。

为什么没有启用 GTX Web 接口？#

GTX Web 对服务器压力比较大，所以默认没有开启。

如果你是在自己电脑上使用这个工具，可以手动开启。请避免在开启全局代理的网络环境下使用该接口，可能会导致翻译异常。

JSON 键名及其局限性#

JSON 数据是以键值对的形式存储的，其中“键”（也称为“名称”）是一个字符串，用于唯一标识数据记录中的特定项目或元素，是数据检索和操作的基础。JsonTranslate 正是利用了 JSON 键名的标识作用来实现精准化识别翻译。

以下是对示例中的几个键名的解释：

• downvote.message：这是一个嵌套的键名。downvote 是外层对象的键名，而 message 是 downvote 对象内部的一个键名。
• 提示词.message：这里 提示词 是一个键名，它本身包含一个对象，该对象有一个键 message。
• share.owner：这个键名包含了一个点（.），它是一个单独的键名而不是指示嵌套关系。在这种情况下，如果你想访问 share.owner 对象中的 name，你不能使用 share.owner.name，因为这会被错误解释为查找一个名为 owner 的对象内的 name 键，而实际上 share.owner 是一个完整的键名。

{
  "downvote": {
    "message": "Downvote"
  },
  "提示词": {
    "message": "prompt"
  },
  "share.owner": {
    "name": "rabbit"
  },
  "data": {
    "title": {
      "id": "001",
      "name": "cabbages"
    }
  },
  "content": [
    {
      "id": "001",
      "value": "Hello, cabbage."
    },
    {
      "id": "002",
      "value": "Hello, Radish."
    }
  ]
}

目前，JsonTranslate 无法处理包含点（.）的 JSON 键名。这是因为点号在 JSONPath 中用于区分嵌套对象的键名，使得含点的键名可能被误解为多层嵌套对象。为避免这一问题，建议使用不含点的键名。