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 和 5 种 LLM（大语言模型）接口，用户可根据需求选择合适的翻译方式：

翻译 API 对比#

• DeepL：适用于长篇文本，翻译更加流畅自然，但不支持网页端 API，需本地或服务器代理调用。
• Google Translate：翻译质量稳定，适用于短句、界面文本，支持网页端调用。
• Azure Translate：支持语言最多，适合多语言翻译需求。
• GTX API/Web：免费翻译选项，适合小规模使用，但稳定性一般。

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

LLM 翻译（AI 大模型）#

本工具提供了 5 种主流 AI 大语言模型（LLM）或接口，分别为：OpenAI、DeepSeek、Siliconflow、Groq 以及 自定义模型（Custom LLM）。

• 适用场景：适合处理语言理解要求较高的内容，如文学作品、技术文档、多语种资料等。
• 可定制性：支持自定义系统提示词（System Prompt）与用户提示词（User Prompt），可灵活调整翻译风格和术语偏好，更好地满足不同使用场景的需求。
• 温度参数（temperature）：可控制翻译结果的随机性。数值越高，生成内容越具创意，但可能影响一致性与准确性。

自定义模型（Custom LLM）支持通过配置 API 接口和模型名称，接入第三方服务或本地推理平台（如 ollama）。例如，默认本地 ollama 的 API 地址为：

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

默认使用模型为 llama3.2。如使用 LM Studio，本地接口地址为：

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

为获得更优的翻译质量，推荐在自定义模型中使用 qwen2.5-14b-instruct 或性能更高的模型。

语言支持#

在多语言翻译能力方面，Google、Azure 和 LLM（大语言模型）均支持上百种语言的互译，而 DeepL 目前仅支持 30 种主流语言。因此，从语言覆盖范围来看，DeepL 相对较弱。

具体的支持语言列表可参考以下官方文档：

• DeepL 支持的语言

• Google Translate 支持的语言

• Azure Translator 支持的语言

功能说明#

映射翻译#

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

翻译缓存#

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

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

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

多语言翻译#

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

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

使用须知#

使用本工具时，请注意以下几点：

• DeepL 支持说明：由于 DeepL API 不支持网页端直接调用，我提供了一个服务器端转发接口，仅用于数据转发，不会收集用户数据。如需提高稳定性，用户也可选择自行部署此接口。

• 使用 DeepLX 免费接口，可能会返回 null。请等一会再使用，或使用自己的 API KEY 或自行部署转发接口。

• API Key 安全：本工具不会存储你的 API 密钥，所有配置数据均保存在本地浏览器中。

• 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 中用于区分嵌套对象的键名，使得含点的键名可能被误解为多层嵌套对象。为避免这一问题，建议使用不含点的键名。