网页设计多语言插件gTranslate，能轻易解决什么问题？以及难以解决什么问题？

内容

1. Overview

2. Proxy Localization

3. 通过gTranslate能实现什么？

   1. 对于新手而言，在30分钟内你能实现这些

   2. 对于新手而言，你很难实现这些

4. Conclusion

Overview

Malibu Beach Inn是我很喜欢的一家位于加州海岸Malibu的酒店，他们有绝佳的海景，和很棒的餐厅。我去玩的时候，酒店游客都来自世界各地。通过smililarweb的web analytics service和旅游网站的评论来看，Malibu Beach inn网站的访问者中，第二大流量来源是德国和意大利。后来在中国的社交平台上，也看见了不少华人在推荐这家酒店。评论里很多人都感兴趣，但也有不少人评论：“我下个月要来洛杉矶玩，想去，但我不太会英文，怎么预定这家酒店呢？”，“酒店餐厅怎么预定？我看不懂”。

当我看到这些潜在客户，因为语言问题，而错过这家完美的度假酒店时，我不仅为游客们感到遗憾，也为酒店感到遗憾----因为，Malibu beach inn有一个很棒的网站，但这个网站只支持英文。在纯英文的网站中，游客只能读懂图片，而不能读懂酒店的预约方式、设施信息、以及客房信息。

网页本地化能带来的好处显而易见，它即能让网站游客们更容易决定预定，也能在游客的本地语言搜索引擎中通过SEO等方式获得更多的宣传曝光机会。

问题来了，如何用低成本、新手友好的方式，实现网站的粗略本地化呢？

方法有很多，但最简易的方法之一是使用：网页翻译代理服务器（Proxy Localization）

gTranslate Dashboarad

gTranslate settings in WP

Proxy Localization

gTranslate，就是本次项目我所选用的网页翻译代理服务器，在它的帮助下，大部分人都能在30分钟内完成网站的粗略多语言化。传统的网页翻译中，用户需要将所有文字导出为XML Localization Interchange FileFormat，然后再在外部编辑器上进行逐句翻译，最后再导入融合进原网站。和传统的TMS不同，在代理服务器的界面上，网页中待翻译文字能被直接选中并实时编辑，这避免了

• 复杂的预设和导入导出流程

• 文字过长过短造成的显示错误

• 多种语言的翻译文件混乱 除此之外，gTranslate类的大多数proxy-translation服务，还能支持多语言一键粗略机器翻译。

基于上述的原因，再因为Malibu Beach Inn目前全网站页面总数不多，文字字数不多（小于10000词），网站结构不复杂，所以我在本项目中选择使用gTranslate，网页翻译代理服务的热门提供商之一。

通过gTranslate能实现什么?

对于新手而言，在30分钟内你能轻易实现这些：

• 添加多种语言

• 在网页中添加语言选择器

• 简易编辑翻译结果

• 一键多语言机器翻译

对于新手而言，你很难实现这些：

如果你没有html基础，或没有wordpress/plugins的操作基础，且只想达成非常粗略的多语言支持，那么上面的效果已经是你能达到的最好效果的（再不花费30个小时进行额外学习的情况下）。不过，随着你的商业帝国不断扩大，下面这些功能一定是你所需要的，届时你将需要请专门的本地化管理者来设置和消除bug。

图片本地化

很多proxy localization服务提供者，在宣传中都会声称他们支持图片本地化（包括gTranslate）。但几乎所有这些提供者所谓的图片支持，都是表面上的虚假支持。真正完整的图片本地化，涉及了multiple desktop publishing的技术和网页编程语言的技术。

例如上图的本地化，从英文到中文，实现起来其实需要较为复杂的步骤，包括在原图的基础上，用图片处理软件，制作对应的中文版图片；将中文图片们上传到wordpress，获得图片对应的url；在原网页html代码中找到原图片在代码中的位置；在代理服务翻译界面，替换url；修复大量的UI bug；等等。如果不是熟练的人来操作，特别是当图片多起来（各个语言加起来超过25张图片时），这个过程会非常容易出错，最后的效果也并不稳定。

网页其他plugin本地化

gTranslate很容易和wordpress的其他插件产生冲突。如果你的网站在使用改变网站界面的插件，例如热门的elementor插件，gutenberg主题插件，smart slider图片美化插件，或者Popup maker简易弹窗制作插件，那准备好面临大量的显示bug吧。

另外，不少插件都会往你的浏览器里存cookie来达到某种功能，而这些cookie又会妨碍你修理bug。例如popup弹窗。当你在修理popup插件和gTranslate插件之间各种冲突的bug时，你必须每次都清理浏览器缓存来检查修理是否成功。

小提醒：为此，最好每次都使用自带无痕浏览模式的浏览器来进行测试。

专业译者管理和权限管理

如果你的网页只有4、5页，而你只想把网站翻译进1~2种语言（例如从英文到你会讲的其他语言），那你一个人可能可以承担文字翻译的工作量。

当网站内容增加后，想象一下

1. 你的网站已经存了20个产品信息和blog，或者

2. 你要将其翻译进1种你不熟悉的语言，或者

3. 你不想再用模糊的不可靠的机器翻译，你想用真正的翻译，再或者

4. 网站内容更新太快（每3天更新）而你忙于商务没有时间立即处理网页本地化。

以上任何一种情况下，你都最好与专业译者合作。gTranslate中有合作者（collaborator）板块，可以添加管理员或译员两种权限的账号，也可管理译员账号可访问的目标语言网页。通过这样简单的设置，你可以确保不同语种的译员之间不会互相干扰，以及译员不会不小心更改你的核心设置。但很多情况下，我们需要更细致的工作分类，以及更自动化的流程，例如工作分配tasks assign，post editing，自动提醒译员新内容发布，上文说到的图片本地化，这些都需要更专业的本地化工具，例如WPML，qTranslate XT等。

Conclusion

如果你的网站构架简单、内容很少、没有需要翻译的图片，那么Proxy localization确实会比较新人友好。因为使用者不需要熟悉网页编程语言，或API或复杂的TMS（translation management system）等等，只需要点击按钮就可以得到一个可读的多语言网站。

但使用Proxy localization会使整个本地化的过程依附于gTranslate插件，会慢慢使用户脱离有序的文件管理体系和高效的工作流程。当将来有一天商业壮大后，大多数用户还是需要用功能更加完整的工具。

看到这里，你的想法可能是：“嗯。。。我先上手用着最简单的工具吧，等今后资金充沛了再用更专业的工具。”

那当你突然发现，多语言Proxy translation的价格是大约15$/月，而WPML的价格是99$/年，时，并且目前的Proxy translation提供商们并不完全支持内容的导出/迁移时，你是否会再多考虑一下呢？