设置使用的翻译服务 translate.service.use
使用方式
translate.service.use('client.edge');
注意，这行代码要加到 translate.execute(); 的前面。
它的值有这几个：
- translate.service 2022.12月，随着 v2.0 版本推出 ，（当前如果不设置，默认便是用的这种）
- client.edge 2024.2月，随着 v3.0 版本推出 ，此能力上线。由微软直接提供翻译支持，不在依赖翻译服务器。
- giteeAI 2025.3月，已完成 DeepSeek、GLM 大模型的稳定使用并在全球龙头企业应用，2025.5月随着qwen3的发布，完成对qwen3的全面对接，2025.7月，跟开源中国联合开发版本完成并发布使用，有开源中国提供算力支持，融入translate.js完成一键接入的深度融合，推出 giteeAI 通道。它不同于上面两个，上面两个是机器翻译，这个是大模型翻译。它提供更好的翻译能力及私有部署后提供毫秒级翻译响应。自giteeAI通道上线后，也就是2025年7月份起，我们强烈推荐采用这个通道，以提供更好的翻译使用体验。 详细可参考： http://translate.zvo.cn/545867.html
translate.service 正常是translate.js中默认使用的，至于为什么是默认使用它而不是默认使用 client.edge、giteeAI ，主要是考虑到v2版本中已经有数十万网站及应用都已经在使用了，为了完美兼容到几年前的旧版本的translate.js
而 translate.service 又可以私有部署到自己的服务器。普通使用都是使用我们公共的翻译服务，也就是我们自己提前部署好了，您可以直接免费去使用，但是如果您对隐私安全要求极高，数据不允许有一点外泄、又或者内网场景不允许通外网时，那么就需要私有部署 translate.service 服务了，部署到您内网自己的服务器来使用。
几种方式的比较
| client.edge | translate.service 开源公共免费翻译 | translate.service 翻译服务私有部署 | |
|---|---|---|---|
| 翻译通道稳定性 | 比较稳定 | 一般 | 非常稳定 |
| 使用群体 | 大众 | 大众 | 仅自己 |
| 翻译字符日上限 | 无上限 | 200万字符/日 | 无上限 |
| 翻译后端API | 不依赖 | 依赖 | 依赖 |
| 是否免费使用 | 免费 | 免费 | 收费 |
| 翻译缓存层数 | 一层缓存-浏览器缓存 | 二层缓存 | 三层缓存 |
| 翻译服务延迟 | 1~5秒的网络+机器翻译延迟 | 命中服务端缓存<2秒延迟 | 命中服务端缓存<100毫秒延迟 |
| 元素整体翻译 | 默认采用 | 默认不采用 | 默认采用 |
| 支持语种数量 | 73种 | 112~450种 | 112~450种 |
| 待补充更多… | … | … |
翻译通道稳定性 translate.service 公共免费翻译 由于是开源公开免费的，所以使用的非常多，同时为了降低服务器的成本，所以会出现偶尔不稳定情况、以及翻译通道延迟或超时情况，比如一天24小时，会有十几分钟的不稳定情况，而且这个情况会随着使用者越来越多也会表现的稍微加剧。所以我们不推荐你使用 translate.service 公共免费翻译 ，而是采用 client.edge、giteeAI 的模式。这里建议用 giteeAI 的模式，是2025.7月最新推出的。有关giteeAI的详细可参考：http://translate.zvo.cn/545867.html
giteeAI 这种是部署了翻译集群，包括欧洲、美洲、亚洲等多个洲都有服务器作为翻译点，同时内置了翻译的自动负载，访问者会自动匹配最优翻译节点的通道，根据当地网络环境等自动进行选择最优切换。翻译服务延迟 是指如果翻译时没有命中浏览器缓存，那么会请求机器翻译接口，将要翻译的文本通过机器翻译接口进行翻译后返回，然后在进行浏览器缓存以及页面翻译。这个请求机器翻译发送跟接收到翻译文本响应的过程，是这里所说的翻译服务的延迟。不过网页基本只要打开翻译过一次了，都会进入浏览器缓存，网页刷新了、切换网页了翻译会极其迅速。