比如直接使用文本翻译API、或打包成APP、桌面客户端应用等使用，这种情况下使用时，是没有域名相关的，所以无法通过域名来进行控制。 ## 前提 需要通过在线方式开通账号， 具体参考： http://translate.zvo.cn/545867.html ## 增加一个UUID 你需要创建一个全部有英文跟数字组合的UUID，记得，一定是全部是英文或数字，不要有其他特殊字符了！ 比如生成的UUID为： ```` 027d360b3c8ec95f1f8809330957fabc ```` 这是一个32位的UUID 然后将这个UUID添加到 http://admin.giteeai.zvo.cn/admin.html 中去。如下图：  这样保存后，我们就能根据添加的这个UUID来使用文本翻译API接口了。 ## 使用 #### 文本翻译接口使用 文本翻译接口的文档参考： http://api.zvo.cn/translate/service/20250814/translate.json.html?domain=https://giteeai.zvo.cn 可以直接点击 **请求** 按钮，即可在线测试接口使用了。如下图：  注意，这里我们使用时，要额外增加一个 key 的参数，值是 你上面增加的uuid。也就是原本post表单提交的这几项数据：  增加key=uuid后 ：  然后再进入 http://admin.giteeai.zvo.cn/admin.html 刷新一下，就能看到已经有数据使用了  #### translate.js 在 html 页面中使用 如果你的场景是介入了 translate.js ， 比如使用uniapp开发后打包成APP、或者混合开发桌面应用，那么你可以这么来使用: 你需要先看一下文档 [网络请求自定义附加参数](471711.html) 追加一行设置: ```` translate.request.appendParams = { key:'027d360b3c8ec95f1f8809330957fabc' } ```` ## 更多扩展说明 [根据翻译接口的响应头来判定是否缓存命中及字符使用](549737.html) [私有部署此服务，翻译量、缓存大小、网站数量、添加的uuid数量等全部无限制](391129.html)

如果你网站中使用了 ````alert(...)````、````confirm(...)```` 会发现，即使你启用了 [监控页面动态渲染的文本进行自动翻译](/4067.html) 但是弹出提示它依旧没有被翻译，因为像是 alert 并不会触发dom的改变，而通常像是弹出提醒现在都是有UI框架提供更好看的弹出提示效果，直接使用js原本的 alert 做弹出提示非常少，所以如果你网页中直接使用了 alert 弹出提示，文字没有被翻译，你可以用第三方的弹出提示来替代 alert ## msg.js 轻量级js消息提醒组件 它是一个轻量级js消息提醒组件，只有几kb，加载中、成功提示、失败提示等，引入msg.js，一句调用，不依赖任何三方js，方便，简单。 具体使用方式可查看开源仓库： Github 仓库使用方式查看 : https://github.com/xnx3/msg | 下载: https://github.com/xnx3/msg/raw/master/msg.js Gitee 仓库使用方式查看 : https://gitee.com/mail_osc/msg | 下载: https://gitee.com/mail_osc/msg/raw/master/msg.js

[TOC] ## 场景 进行网页浏览时，当前网页是中文的，通过切换语种切换成了英文，当点击这个网页中的超链接后打开新页面进行浏览时，发现新页面会先显示原本的中文内容，1秒后才变成了英文内容 ## 解释 新打开的页面先显示原本的中文内容，是因为 translate.js 会有个翻译的过程，并不是实时立即就翻译完毕，它会有个计算过程，所以会有个延迟，也就出现了这个所为的1秒的延迟效果。以后随着后续AI算力芯片的提升，这个延迟效果会进行逐渐缩短。 另外新页面第一次打开，内容以前没有被翻译过的，才会有这个1秒的切换效果，如果你已经打开过一次翻译过了，当你在进行刷新页面时，是没有这个1秒切换效果的，而是打开后立即显示的就是英文，不会再有先显示中文在切换英文的过渡，因为translate.js 它本身有一层浏览器级别的缓存，你浏览器打开翻译过一次后，它就将翻译结果进入了浏览器缓存，你刷新页面后，它会直接从缓存中取出翻译结果赋予页面，这个过程非常快，人眼是感知不出来的，所以感觉上是打开后直接就是英文的。 ## 优化 如何能让访客在第一次访问时（也就是访客的浏览器本身没有翻译缓存时），也能做到极速翻译切换的效果，避免出现中文或者降低中文出现的时间？ #### 方式一： 采用 [离线翻译](https://translate.zvo.cn/4076.html) 的能力，离线翻译是不依赖自动化翻译，而是跟传统的i18n的原理类似，提前讲某段文字对应语种的译文提前以代码的方式配置好了，当用户打开页面浏览时，程序会自动从配置里讲译文取出迅速进行翻译，完全规避用户视觉上出现先中文，卡顿一下再出现英文的视觉感知。而是直接打开后直接就是英文的。 但是这个方式是有个缺点的，这个缺点就是传统 i18n 的缺点，需要提前进行配置，只不过 translate.js 会简单非常多，它可以一键导出来。 在一些正常使用的场景中，可以这么考虑，在网页的第一屏出现的文字用离线翻译配置好，那么用户访问时，第一屏是最先看到的，而后面向下滑动才能看到的文字，可以依旧用 translate.js 的自动化翻译来进行，这样对技术的工作量是比较少的。 #### 方式二： [启用GiteeAI企业级翻译通道](545867.html) 它跟开源的翻译通道相比，它是独立的，用户没有那么多，且是大模型翻译，有开源中国提供所有的算力支持。 它有两层服务端的翻译缓存，如果你本身的页面的文字是固定的（是指整个页面翻译的文字是固定的，比如你要翻译的文字中有当前时间的，当前时间肯定每次看都是变化的，那这个就不是固定的，有变动了），翻译后服务端会进行一次结果的缓存，当下一次在进行翻译时，他会直接从缓存中吧结果返回，极大降低这个耗时。 如果已经翻译过一次，访问时命中缓存，它从开始网络请求到翻译完成的时间大概不到200毫秒，会非常迅速。 ## 隐藏原文 1. [网页打开时自动隐藏文字，翻译完成后显示译文](549731.html) 2. [启用翻译中的遮罩层](407105.html) 这两个的作用是，当切换页面时，网页中的原文会先隐藏，不会先显示出来，避免出现先显示原文一瞬间又切换到译文的那种视觉的不舒服。 在一个是如果本身网页端没有缓存，通过服务端进行翻译时，它还会再要翻译的文本上出现一个加载中的动画，给用户一种非常好的视觉体验。 如果你使用这两个后，发现还是不满意，可以[联系我](4030.html)，来做完美的适配

```` corsican:科西嘉语 guarani:瓜拉尼语 kinyarwanda:卢旺达语 hausa:豪萨语 norwegian:挪威语 dutch:荷兰语 yoruba:约鲁巴语 english:英语 gongen:贡根语 latin:拉丁语 nepali:尼泊尔语 french:法语 czech:捷克语 hawaiian:夏威夷语 georgian:格鲁吉亚语 russian:俄语 chinese_simplified:简体中文 persian:波斯语 bhojpuri:博杰普尔语 hindi:印地语 belarusian:白俄罗斯语 swahili:斯瓦希里语 icelandic:冰岛语 yiddish:意第绪语 twi:契维语 irish:爱尔兰语 gujarati:古吉拉特语 khmer:高棉语 slovak:斯洛伐克语 hebrew:希伯来语 kannada:卡纳达语 hungarian:匈牙利语 tamil:泰米尔语 arabic:阿拉伯语 bengali:孟加拉语 azerbaijani:阿塞拜疆语 samoan:萨摩亚语 afrikaans:南非荷兰语 indonesian:印尼语 danish:丹麦语 shona:修纳语 bambara:班巴拉语 lithuanian:立陶宛语 vietnamese:越南语 maltese:马耳他语 turkmen:土库曼语 assamese:阿萨姆语 catalan:加泰罗尼亚语 singapore:僧伽罗语 cebuano:宿务语 scottish_gaelic:苏格兰盖尔语 sanskrit:梵语 polish:波兰语 galician:加利西亚语 latvian:拉脱维亚语 ukrainian:乌克兰语 tatar:鞑靼语 welsh:威尔士语 japanese:日语 filipino:菲律宾语 aymara:艾马拉语 lao:老挝语 telugu:泰卢固语 romanian:罗马尼亚语 haitian_creole:海地克里奥尔语 dogrid:多格来语 swedish:瑞典语 maithili:迈蒂利语 thai:泰语 armenian:亚美尼亚语 burmese:缅甸语 pashto:普什图语 hmong:苗语 dhivehi:迪维希语 chinese_traditional:繁體中文 luxembourgish:卢森堡语 sindhi:信德语 kurdish:库尔德语（库尔曼吉语） turkish:土耳其语 macedonian:马其顿语 bulgarian:保加利亚语 malay:马来语 luganda:卢干达语 marathi:马拉地语 estonian:爱沙尼亚语 malayalam:马拉雅拉姆语 deutsch:德语 slovene:斯洛文尼亚语 urdu:乌尔都语 portuguese:葡萄牙语 igbo:伊博语 kurdish_sorani:库尔德语（索拉尼） oromo:奥罗莫语 greek:希腊语 spanish:西班牙语 frisian:弗里西语 somali:索马里语 amharic:阿姆哈拉语 nyanja:齐切瓦语 punjabi:旁遮普语 basque:巴斯克语 italian:意大利语 albanian:阿尔巴尼亚语 korean:韩语 tajik:塔吉克语 finnish:芬兰语 kyrgyz:吉尔吉斯语 ewe:埃维语 croatian:克罗地亚语 creole:克里奥尔语 quechua:克丘亚语 bosnian:波斯尼亚语 maori:毛利语 ````

## 注意 这是使用translate.js 中默认内置的开源翻译通道才会有这个限制，而你上线的项目，我们建议你采用启用了内存缓存跟文件缓存的giteeai通道，来提供极速的翻译通道支持。具体可参考： [项目上线 - 更换更稳定响应更快翻译更好的大模型翻译通道](545867.html) ## 说明 首先很荣幸，我们的多语言翻译的项目能被贵方采纳，能被您认可、以及能对更多的朋友提供便利，我们也非常高兴。2023.7月底，后端翻译的请求量已达到 1.5亿次/月，而到了24年底，更是达到了60亿次/日的恐怖增速，其中包括一些城投集团、政府单位像是环境保障局、企业国际化经营服务平台、政务服务网等等被广泛使用，并且还在非常快速的持续增大，这对于我们后端翻译服务器来说，造成了不少压力。 起因是一个海外的盗版小说站使用，因为他们是盗版，没有留任何联系方式，我想给他发邮件联系他给他私有部署，但没有他的联系方式，根本联系不到对方，才无奈增加了一个每日翻译字符上限的拦截，避免被大量占用影响正常用户使用，因为联系不到对方才加的拦截，因为据我们统计，一般的网站使用量也只是在30万以内字符，可以说99%的网站每日翻译字符都是在50万以内的，而我们所统计的除了那个小说站外，多的一天使用量也就二百多万翻译字符左右，所以我们才加了一个上限是100万的限制，目的是为了让所有正常用的都能没问题。而且正常使用如果您发现超过这个上限，看到这个说明了，没关系，您可以有以下两种方式来增加每日翻译的字符上限

对文本进行翻译，传入一句或多句文本，设定上要翻译为什么语种，比如英文，它会立即进行翻译给你返回。 ## API文档 http://api.zvo.cn/translate/service/20250814/translate.json.html 这个API文档提供快速测试及参考，真正使用时要针对这个文档进行以下调整： ## 真正对接及使用要进行几处调整： #### 1. 请求url 调整 请求URL改为： https://america-enterprise-api-translate.zvo.cn/translate.json #### 2. 传入参数调整 传入参数新增两个参数传入： | 参数名 | 示例 | 说明 | | ------------ | ------------ | | cache | 0 | 缓存控制，这里固定传入 0 | | key | xxxxxxxxxxxxxxxxxxxxxxxxx | [企业版翻译通道](43262.html)我们给你开的key | | lowercase | 0 | 翻译结果是否需要段落首字母大写？
如果需要段落首字母大写就传入0
否则不传入则默认是1采用全小写形态 | ## 其他说明 #### 如何查看我的每日翻译字符数 在翻译的响应头会有返回。具体可参考： [每日翻译字符数查看](43496.html) #### 支持的语种列表一览 ```` corsican:科西嘉语 guarani:瓜拉尼语 kinyarwanda:卢旺达语 hausa:豪萨语 norwegian:挪威语 dutch:荷兰语 yoruba:约鲁巴语 english:英语 gongen:贡根语 latin:拉丁语 nepali:尼泊尔语 french:法语 czech:捷克语 hawaiian:夏威夷语 georgian:格鲁吉亚语 russian:俄语 chinese_simplified:简体中文 persian:波斯语 bhojpuri:博杰普尔语 hindi:印地语 belarusian:白俄罗斯语 swahili:斯瓦希里语 icelandic:冰岛语 yiddish:意第绪语 twi:契维语 irish:爱尔兰语 gujarati:古吉拉特语 khmer:高棉语 slovak:斯洛伐克语 hebrew:希伯来语 kannada:卡纳达语 hungarian:匈牙利语 tamil:泰米尔语 arabic:阿拉伯语 bengali:孟加拉语 azerbaijani:阿塞拜疆语 samoan:萨摩亚语 afrikaans:南非荷兰语 indonesian:印尼语 danish:丹麦语 shona:修纳语 bambara:班巴拉语 lithuanian:立陶宛语 vietnamese:越南语 maltese:马耳他语 turkmen:土库曼语 assamese:阿萨姆语 catalan:加泰罗尼亚语 singapore:僧伽罗语 cebuano:宿务语 scottish-gaelic:苏格兰盖尔语 sanskrit:梵语 polish:波兰语 galician:加利西亚语 latvian:拉脱维亚语 ukrainian:乌克兰语 tatar:鞑靼语 welsh:威尔士语 japanese:日语 filipino:菲律宾语 aymara:艾马拉语 lao:老挝语 telugu:泰卢固语 romanian:罗马尼亚语 haitian_creole:海地克里奥尔语 dogrid:多格来语 swedish:瑞典语 maithili:迈蒂利语 thai:泰语 armenian:亚美尼亚语 burmese:缅甸语 pashto:普什图语 hmong:苗语 dhivehi:迪维希语 chinese_traditional:繁體中文 luxembourgish:卢森堡语 sindhi:信德语 kurdish:库尔德语（库尔曼吉语） turkish:土耳其语 macedonian:马其顿语 bulgarian:保加利亚语 malay:马来语 luganda:卢干达语 marathi:马拉地语 estonian:爱沙尼亚语 malayalam:马拉雅拉姆语 deutsch:德语 slovene:斯洛文尼亚语 urdu:乌尔都语 portuguese:葡萄牙语 igbo:伊博语 kurdish_sorani:库尔德语（索拉尼） oromo:奥罗莫语 greek:希腊语 spanish:西班牙语 frisian:弗里西语 somali:索马里语 amharic:阿姆哈拉语 nyanja:齐切瓦语 punjabi:旁遮普语 basque:巴斯克语 italian:意大利语 albanian:阿尔巴尼亚语 korean:韩语 tajik:塔吉克语 finnish:芬兰语 kyrgyz:吉尔吉斯语 ewe:埃维语 croatian:克罗地亚语 creole:克里奥尔语 quechua:克丘亚语 bosnian:波斯尼亚语 maori:毛利语 ````

对html源码进行翻译，传入一个html源文件，设定上要翻译为什么语种，比如英文，它会立即将当前html文件转换为英文输出。 ## 请求url ` https://translate.apistore.huaweicloud.com/html ` ## 请求方式 method `POST` ## 请求头 header ```` Content-Type:application/x-www-form-urlencoded X-Apig-AppCode:41c5899dfdf247fc8b999318c17936521c60f13de5g348d38636e069297e95df ```` 其中的 `X-Apig-AppCode`参数是通过 https://marketplace.huaweicloud.com/contents/b042e7ed-a5a1-48fb-8328-91762ef67312 购买后获得的，购买后查看方式如下图   ## 传入、返回参数 传入参数及相应参数请参考： http://doc.zvo.cn/tcdn/api/doc.html ## CURL 调用接口请求示例 ```` curl --location --request POST 'https://translate.apistore.huaweicloud.com/html' --header 'X-Apig-AppCode: appcodexxxxxxxxxxxxxxxxxxx' --data-urlencode 'html=

哈哈，我是测试的第一行文本

' --data-urlencode 'language=english' ```` 将其中的 ````appcodexxxxxxxxxxxxxxxxxxx```` 换成你从华为云购买后获取到的 appcode ，即可直接使用了 ## API接口调试工具 https://apifox.com/apidoc/shared-a84837d4-1580-4ae2-9e3d-26915c6dbd54 ## 支持的语种列表一览 ```` corsican:科西嘉语 guarani:瓜拉尼语 kinyarwanda:卢旺达语 hausa:豪萨语 norwegian:挪威语 dutch:荷兰语 yoruba:约鲁巴语 english:英语 gongen:贡根语 latin:拉丁语 nepali:尼泊尔语 french:法语 czech:捷克语 hawaiian:夏威夷语 georgian:格鲁吉亚语 russian:俄语 chinese_simplified:简体中文 persian:波斯语 bhojpuri:博杰普尔语 hindi:印地语 belarusian:白俄罗斯语 swahili:斯瓦希里语 icelandic:冰岛语 yiddish:意第绪语 twi:契维语 irish:爱尔兰语 gujarati:古吉拉特语 khmer:高棉语 slovak:斯洛伐克语 hebrew:希伯来语 kannada:卡纳达语 hungarian:匈牙利语 tamil:泰米尔语 arabic:阿拉伯语 bengali:孟加拉语 azerbaijani:阿塞拜疆语 samoan:萨摩亚语 afrikaans:南非荷兰语 indonesian:印尼语 danish:丹麦语 shona:修纳语 bambara:班巴拉语 lithuanian:立陶宛语 vietnamese:越南语 maltese:马耳他语 turkmen:土库曼语 assamese:阿萨姆语 catalan:加泰罗尼亚语 singapore:僧伽罗语 cebuano:宿务语 scottish-gaelic:苏格兰盖尔语 sanskrit:梵语 polish:波兰语 galician:加利西亚语 latvian:拉脱维亚语 ukrainian:乌克兰语 tatar:鞑靼语 welsh:威尔士语 japanese:日语 filipino:菲律宾语 aymara:艾马拉语 lao:老挝语 telugu:泰卢固语 romanian:罗马尼亚语 haitian_creole:海地克里奥尔语 dogrid:多格来语 swedish:瑞典语 maithili:迈蒂利语 thai:泰语 armenian:亚美尼亚语 burmese:缅甸语 pashto:普什图语 hmong:苗语 dhivehi:迪维希语 chinese_traditional:繁體中文 luxembourgish:卢森堡语 sindhi:信德语 kurdish:库尔德语（库尔曼吉语） turkish:土耳其语 macedonian:马其顿语 bulgarian:保加利亚语 malay:马来语 luganda:卢干达语 marathi:马拉地语 estonian:爱沙尼亚语 malayalam:马拉雅拉姆语 deutsch:德语 slovene:斯洛文尼亚语 urdu:乌尔都语 portuguese:葡萄牙语 igbo:伊博语 kurdish_sorani:库尔德语（索拉尼） oromo:奥罗莫语 greek:希腊语 spanish:西班牙语 frisian:弗里西语 somali:索马里语 amharic:阿姆哈拉语 nyanja:齐切瓦语 punjabi:旁遮普语 basque:巴斯克语 italian:意大利语 albanian:阿尔巴尼亚语 korean:韩语 tajik:塔吉克语 finnish:芬兰语 kyrgyz:吉尔吉斯语 ewe:埃维语 croatian:克罗地亚语 creole:克里奥尔语 quechua:克丘亚语 bosnian:波斯尼亚语 maori:毛利语 ````

您可以实时查看您某个网站（域名）的每日翻译字符使用情况。 注意，这种方式是针对使用了 [translate.service 翻译方式的](43086.html) ，另外需要说明的是，[企业版高稳定翻译通道](43262.html) 使用的便是这种方式 ## 查看方式 审核元素，然后随便翻译一下，找到 translate.json 的请求，如下图所示  * **Day_current_size** 是今天已经使用的翻译字符数 * **Day_max_size** 是当前的字符限制，你这个域名每天能有多少翻译字符 如果您追求高质量、高效、高稳定，推荐您采用企业版本的翻译，会让您更好的使用、异常指导等。

## 现状 当前 translate.js 用于常规的html中，但是在一些框架中，比如react、vue、uniapp等，他们都有自己的语法规范，如果按照常规的translate.js使用方式，在这些框架中使用，使用者需要付出不少的精力去不断尝试，会消耗使用者很多精力、无谓的踩坑。 开发者可以对其进行进一步的适配包装，让某个框架的使用者可以按照固有的步骤，一步步就能完成接入使用。比如这个： http://translate.zvo.cn/42048.html ## 开发者合作 我们希望开发者可以再我们 translate.js 的基础上进行扩展，比如进行uniapp、vue2、vue3、react、…… 各种前端框架， 还有以及各种管理后台框架如 tiny、 ruiyi…… 等等，进行适配或接入。让 translate.js 能彻底解放前端开发者未来再国际化方面的开发投入。使开发者无论做什么项目，它都是支持国际化的，而不需要在做额外的工作！ ## 开发者收益 * 您开发的翻译插件，您可以发布到其应用市场，进行收费。在这方面，[discuz的哥们做的就很棒，插件已获得万+的收入](https://addon.dismall.com/plugins/domi_translate.html) 这些费用都是你自己的。我们也是完全认可并允许的。 * 如果你是技术，也不懂推广，也没法很好的沟通客户，你可以将你这个插件托管到我们这边，我来帮你推广及对接客户。比如你针对vue、react 等框架做的插件，如果有这方面需要时，这些插件被使用，我们作为一个中间方进行介入 * 保障你的插件没有问题付费者能正常使用 * 避免使用者能用了，钱不给了的情况，我们会中间做托管，使用者先支付过来费用，在使用您的插件，如果使用者用不起来，钱还会给人原样退回去。 * 使用后一个月内没什么问题，费用在转到您的账户中。其中我们会抽里面的30%作为我们参与推广、对接用户、协调等的费用。 * 您还可以直接将您做的这个插件无偿贡献出来，合并到我们 translate.js 的主仓库中，以后无论是找工作、还是吹牛，你都可以自豪的说，那个translate.js的AI前端国际化全球第一的项目，它之所以那么多人用，因为里面有某某功能是我做的。 我们也会在主页及 README.md 中为你署名。 * 企业版通道收费分成。使用者如果用你做的插件，向我们购买 [企业版稳定翻译通道](https://translate.zvo.cn/4087.html) ，您作为插件的作者，可以获得10%的分成！ 而购买企业版通道这事，你完全无需任何参与、推广、沟通客户、等等一系列问题，全部有我们同事接管，你只管拿分成！ * 赠送[企业版稳定翻译通道](https://translate.zvo.cn/4087.html) （600元/年）永久使用。 只要您的插件一直有效并且能正常使用，出bug积极配合修复，我们会赠送你一个 [企业版稳定翻译通道](https://translate.zvo.cn/4087.html) 并且无时间限制。 你可以自己用，也可以送人。你的付出，我们认可，并给与感谢！ * 任务外包。我有一家网络公司是外包性质的，技术部只有项目经理的角色，结过活来后，项目经理会吧任务分解，然后将前端了、后端了、等分好模块外包出去做。给擅长的人做擅长的任务，提高效率，降低成本，同时还能给第三方带来收益。在当前不景气的经济环境下也能缓解第三方资金上的压力。因为你参与，起码也是证明了你技术的过硬，我们对外分配的任务会优先向你倾斜。 ## 当前使用情况 本项目始于2021年，2022年全部重构推出v2版本，23年初使用量已经达到每月六千万次，2023年底推出v3版本前，使用量已经达到每月40亿+，并以及其迅猛的速度快速增长。所以23年底推出v3版本进行去中心化服务器，以应对更加庞大的使用量。 目前像是 Discuz、易优CMS、迅睿CMS、……等应用市场都有本插件的包装版本上架并进行销售，而且也取得了比较丰富的收益！重点是我们完全支持这样做，而且开发时遇到任何技术问题我提供全程参与指导、以及插件推广也会挂到我们主页中！ ## 我能给与哪些支持 1. 您做应用或插件适配时，我提供全程技术指导，有必要可以拉我进行在线会议实时沟通 1. 您做的应用或插件，所给你带来的收益，我们完全支持并认可。 1. 在我们官方首页位置、以及开源仓库介绍中，加入您应用或插件的链接入口，帮您推广 ## 联系 有意向的朋友，欢迎加我微信 17076012262 也可直接打我这个电话，说一下你想开发哪方面的插件、需要我提供什么支持等

这个目前是第一次切换语种时，不会刷新页面，但是第二次或以后切换语种时，会刷新页面。 也就是比如，你当前页面本身是简体中文，你切换成了英文，并不会刷新页面，但是你切换成英文后，在想切换成法语等别的语种时，就会先刷新当前页面，再切换成法语。 有好几个朋友都提过这个问题，为什么不做到无刷新切换呢？首先这个需要开发，而且搞这个会投入不小精力，最重要的一点是，我认为这个需求并不是非常需要的。作为一个正常的用户，用户的需求并不是去帮你做测试的，而是去使用你的本身的产品！如果用户去不断的切换语言，这只能说明这个用户带着试试的态度，探寻的目的去看看它能不能真的切换，切换后是什么样子，它的重点已经不是全部放在你本身的产品上了。 另外还有人提过，用户已经看了一些内容了，刷新后再看，如果我做的是类似今日头条这种每次打开都会推荐不同的内容，那岂不是用户看了一半然后一切换就找不到了吗？ 可是用户既然要切换语言，证明当前的语种就是自己不熟悉的，都不熟悉怎么会先看一半？ 经过综合评估，感觉这个功能的投入时间跟实际作用并不成正比，只是感觉上这个效果挺好，但是实际呢，也就只是开发者、测试人员感觉挺好。 如果您的老板强烈要求你必须增加无刷新翻译的功能，并且您的老板可以提供一点点赞助，我们可以做无刷新切换

如果使用方式没问题，是 translate.js 本身翻译出现了bug，那么可以联系作者进行排查并将进行修复。 为了方便进行排查，您需要把您的项目进行一些操作，使其最终给到我时，可以达到以下条件 1. 我可以本地不需要安装任何环境了准备了，直接双击就能在浏览器中打开调试，比如 demo.html 2. 也或者我可以直接把你给我的直接丢到tomcat中就能访问调试 3. 把问题能复现出来，不要教我怎么第一步，怎么第二步，怎么第三步。。。。尽量简化这个步骤，简化到一两步内就能复现我就能调试 4. translate.js 这个文件可以放在跟你给我的demo.html 文件同目录，demo.html文件你可以被压缩、被加密等都没关系，我只需要能改动 translate.js进行调试就可以 5. 尽量把无关的东西删一删，不然给到我看着乱七八糟一大堆影响调试我也要自己来删，尽量提高我调试的效率 需要满足以上几点，然后把你弄的这个文件或文件夹直接发我，我来帮你解决问题。免费。

## 使用 ```` translate.service.use('client.edge'); ```` 这个要加到 ````translate.execute()```` 之前 ## 注意 1. 这个是一个临时方法，内测完成后，translate.js默认便会直接带着这个设置，不需要在加这一行设置代码 1. 需要 translate.js 的版本为 2.11.7.20240122 ， 可直接使用 https://res.wang.market/translate/translate.js ## 带来的改变 ##### 首先，先感谢微软为此提供的翻译服务！ 1. 使用它后，不再有日翻译字符上限！就算你网站一天翻译一百亿字符都可以。 1. 使用它后，不再给你网址进行翻译字符数统计（因为不再有字符限制了） 1. 使用它后，不再局限于本地的几种语种了，例如你可以在日文网站上用（待大量实践验证） 1. 使用它后，你的翻译语句更通顺了，比如它来翻译文档或者小说，更易于阅读了。 1. 未来translate.js翻译的走向是倾向于这个的，待验证此中方式无任何bug后，默认将会使用此方式。一些显著的使用比如，不需要再用代码设置本地语种是什么 1. 我们计划于年前推出 chrome 的一键翻译插件，以解决 chrome浏览器在中国境内“一键翻译为中文”无法使用的问题。而这个插件的核心，便是此。它会给网站带来通用的适配，网站不再需要单独进行设置，不需要前端技术使用代码进行单独适配了。 1. 更好的自动容错能力，你对前端不需要太了解，就能非常好的把它植入你的网站中

为了使用户有更好的体验，我们在v2版本时便加入了两级缓存机制。 而在 v3.14 版本时，又增加了一层内存级缓存，支持三级缓存的能力，进一步提升瞬间翻译能力。 * **一级缓存-浏览器缓存，缓存于浏览器。** 用户翻译过一次，那么浏览器就会进行缓存相应的翻译句子。当用户刷新页面时，将不会再从后端接口来取翻译结果，而是直接从浏览器本身的缓存中进行识别进行翻译。极大提高用户体验，使网页翻译无需在有缓冲等待。这层缓存是用的浏览器的 LocalStorage 进行的缓存，可以通过审核元素来查看相关缓存信息。 * **二级缓存-文件缓存：缓存于服务器。** 翻译过一次的，都会在服务端进行缓存。下次当有翻译请求时，如果要翻译的内容跟要翻译的语种相同，那么将直接从服务端缓存返回响应，而不需要再通过第三方翻译平台来进行翻译，从而极大降低了在第三方翻译平台的翻译字数。 注意，当前缓存的方式，是一个翻译的API请求中所有的文本能完全匹配，才会走缓存。如果你网页是静态网页，翻译的文本本身并不会变，那就会走缓存。如果你网页中有动态文本，比如你的是论坛，会显示最新用户发帖跟最新评论，这个是每次打开网页时它都会变的，所以就会导致翻译时文本每次都是不同的，那这样就不会匹配到缓存，而是进入了第三方翻译接口进行翻译。当然这个翻译因为有了一级缓存的存在，浏览器本身就进行了识别，在请求过来的也只是这个有变化的文本，也就是上面所提的用户发帖跟最新评论，只是这些变动的，在浏览器一级缓存中并没有被翻译过的句子，才会经过第三方翻译接口进行翻译。实际翻译的字数也不多，只是那几句有变化的句子而已。 它的缓存方式是采用文件式缓存来进行存储，我们的开源免费版本用的也是这种缓存方式，它跟 HDD 磁盘进行结合，可以极大降低服务端成本。v2版本也是因此，在翻译速度方面提升了非常大。 * **三级缓存-内存缓存：缓存于服务器。** 它采用的是内存级的缓存方案，它弥补了二级缓存（文件缓存）对于像论坛等动态内容缓存命中率低的不足，他会对每行翻译文本进行单独的缓存命中，而翻译之后也会对每行进行单独的缓存。这样极大提高了文件缓存没命中的情况下，再有内存缓存进行的每行文本的缓存命中。使真正使用机器翻译及大模型翻译的文本极少极少。我们所知大模型的计算效率、以及token数是花钱的，经过缓存后，可以极大的降低对大模型的使用消耗。 比如```` ["你好","世界","我是智能翻译"] ```` 这里有三个要进行翻译的，它在内存缓存中寻找，是 ````"你好"````、````"世界"````、````"我是智能翻译"```` 分别进行了三次缓存寻找，比如 ````"你好"````、````"世界"```` 这两句缓存中都有，那么直接从缓存中取出翻译结果， 而 ````"我是智能翻译"```` 缓存中没有，则只讲这一个交给机器翻译或者大模型去进行翻译，翻译之后再将 ````"我是智能翻译"```` 的翻译结果存入内存缓存中以便后续使用。 注意，三级缓存（内存缓存）是直接占用内存的，而一般的服务器内存还是要稍微贵点的，所以开源版本本身是不支持内存缓存的，只有私有化部署的版本才可选择启用三级缓存，用内存来介入进行逐行缓存。

每天都有很多朋友因为前端缺失或者不太熟练，使用过程中出现了一些异常希望我们能帮忙，但是本项目使用量非常多，本人精力实在有限有些顾不过来，拿一个数据来说，在 2023.6 月份时，本项目的后端免费翻译服务的请求量就已经达到了 1.5亿次/月，2024年初，已经达到40亿/月的规模， 并且还在非常快速的持续增大，包括一些城投集团像是长沙城投、以及一些政府单位像是环境保障局、企业国际化经营服务平台、海外矿业产业联合、国际潮青联谊年会、人力资源和社会保障局、政务服务网、另外一些框架比如 [wangmarket CMS](http://cms.zvo.cn)、[Layui](https://gitee.com/mail_osc/translate_layui) ，还有一些平台如futrom智能住宅、bitheime全球区块链等等都在广泛使用，每天也都有很多新朋友在积极接入，每天都会有几十次协助请求，为了让更多的朋友能更好的使用、减少等待，提供更好的服务，我们为此专门抽了一个前端同事来负责提供帮助，按照 62.5元/h 的费用标准来让前端同事进行提供服务（如果超过8h，超过的时间费用上涨为80元/h）。像是html页面、VUE、uniapp 等都能使用这个翻译，但是微信小程序因为它的原理特性不能使用这个翻译，这个需要知晓。 翻译能力是本人的一个开源作品，本人除此之外还有其他四十余个开源作品，所以作者本人的精力着实是有限，但为了能保障使用者能更好的使用，无奈出了这种服务措施。如果您手头资金并不宽松，建议您可以多多进行尝试、或在QQ群 181781514 沟通交流。 如果您公司有相关预算，可以考虑采用我们的前端来提供协助，让我们前端来帮您去做。但是需要了解的是，我们的前端也不是万能的，如果我们翻译本身不支持或者一些别的情况，我们只是站在我们的角度，更熟悉它的角度，来帮您。 如果您需要此服务，可以加我微信 xnx3com 然后将您的需求或者问题简单整理一下发我、同时转账 200元费用，我们给排上技术人员将在2天内给咱提供一对一协助。实际费用解决完后根据实际工时进行计算，工时按照62.5/h 计算，多退少补。 进行协助前，我们强烈建议您先提前梳理好需要前端技术帮助的地方，前端技术进行介入时，会拉一个线上的腾讯会议，通过会议实时沟通，必要时可以分享屏幕，以求效率最大化。前端需要做什么，您安排，前端技术人员根据你的指示去做。

## 功能概述 提供开放API，对 html文件（html源代码）进行语种翻译，比如将中文、英文网页翻译为俄语、韩语等。 支持百余种语种的翻译。 它可完美支持识别各种复杂及不规范html代码。 支持翻译前的微调，比如不翻译某个区域、图片翻译、操作html文件中的元素进行增删改等。 ## 常见使用场景 1. 外贸站，针对本身一个语种的网站页面，全自动生成其他语种的网站静态页面，并且推送到相应的语种搜索引擎收录 2. 跟邮箱结合，对邮件进行一键自动翻译为自己熟悉的语种进行阅读 3. 针对搜索引擎收录，批量将网页翻译为某个小语种，推送到其搜索引擎进行收录，占领搜索引擎流量入口。 4. 跟IM聊天结合，对IM聊天中的某些有格式的文本进行翻译，翻译后还能保留之前原本的格式给用户观看。 5. 跟文档站结合，比如 readme.md 、 文档阅读站，对文档整体增加一键翻译能力 6. 跟AI智能体 agent 集合，对智能体产生的内容进行翻译后输出，同时完美保留智能体输出的格式版面 7. 更多...... ## 应用生态建设 我们鼓励开发者基于本接口做的具体某些行业的应用及服务，应用对接期间我们全程提供参与指导，并且所有API接口调用全面免费提供给与最大支持。 我们希望你的应用是可以给用户私有部署或者销售授权，这样我们双方可以进行深度捆绑利润共通，我们也会在我们官网中向用户推荐您的应用。 另外您的应用在服务客户时，使用我们API接口会以至少低于正常销售价格一半及以上的超低价给你提供，用户可以通过你直接购买API。如果您有其他的合作想法都可以联系我 17076012262 微信同号，进行详谈。 ## API接口 #### 快速体验  API接口详细介绍及在线测试可参阅： http://doc.zvo.cn/tcdn/api/doc.html #### 接口实际使用 跟上面快速体验的接口相比，实际使用的接口不同点有两处，一是url不同，再一个是header中额外增加了一个X-Apig-AppCode传入，这个也就是授权码的作用，每使用一次，使用次数便会减去1。 请求url：`https://translate.apistore.huaweicloud.com/html` 请求头 header增加一项： `X-Apig-AppCode:41c5899dfdf247fc8b999318c17936521c60f13de5g348d38636e069297e95df` 具体接口说明可以参见： http://translate.zvo.cn/43705.html ## 价格 此能力是我们历时3年独立研发，将运行成本全方位大幅降低！比如某度翻译的同类产品大概0.5元/次，而我们可以做到 0.01元/次甚至合作方享受更低价格。 （价格根据合作方式可以变动，具体可以详谈，不止局限于当前价格） 使用成本的大幅，可以让你去做更多你想做的应用。 ## 战略合作 我们希望跟各地有销售能力、或者你的客户可能是有这种html翻译需求（比如有客户是做外贸站的）的公司合作，AI时代以来，传统的软件定制，必然会如上个时代工厂替代手工业般被无情取代，加入我们，抓住AI的机遇，必定会有收获。 只要你有想法，欢迎跟我联系 17076012262 （微信同号） 商讨合作契机。