我没有看到过另一个这样的翻译系统,可能是因为以下原因。尽管SimplePO网站上写着的不一样,但翻译人员不喜欢并且通常不会使用如上所示的并排翻译系统。
这就是程序员想象中翻译人员的工作方式,但这是有缺陷的。翻译人员使用一个称为TMX(Translation Memory Exchange)的工具包(通用名称,请参见开源实现Okapi以了解其感觉),在其中建立单词、短语和句子的翻译字典。然后,他们将各种格式的文件输入到TMX软件中,这给他们提供了第一遍翻译,翻译率为60%、70%等,但像Google语言API一样,在目标语言中难以理解。
然后,他们翻译未被TMX处理的单词,并在逻辑上添加到字典中,并使其口语化,即使其在目标语言中起作用并有意义。因此,翻译人员应始终将其翻译成母语。
他们之所以这样做,有很多原因:a)这是有道理的,有效的,可以减轻他们的工作量;b)因为他们按单词计费,而并排翻译不允许他们使用工具并最大化收入。
翻译相关的内容:译者想要的是一个可以导出、他们可以导入和翻译、再导出并发送回您进行导入的文件格式。
文件格式可以是csv、rtf、tmx、xliff、gettext,如果您阅读Symfony框架文档,您可以看到他们如何处理它(在我看来,他们做得相当不错)。
话虽如此,大约8年前,当我需要用英语、法语、德语、匈牙利语和斯洛伐克语编写网站时,我处于类似的位置,我和SimplPO一样,只是编写了自己的并排应用程序来完成这项工作。然而,我们为应用程序编写的公司都是自己内部进行翻译的,所以我们没有遇到与翻译人员有关的问题。当我们遇到问题时,我们编写了一个RTF导出和导入(这本身就令人费解),以便翻译人员可以像上面那样工作。
然而,SimplePO是我见过的唯一其他实现这个想法的东西。像Zend这样的框架似乎认为你只需创建查找标记来替换单词和短语,并且不会在应用程序中构建任何控件来管理该过程。因此,它很快失控,维护它变得既困难又昂贵。
大多数编写多语言网站的人实际上并没有这样做。他们编写一个主站点,然后复制它,翻译它并维护翻译版本。对于我们这些逻辑类型来说,这似乎很笨拙,但实际上非常有效。
它有效的原因之一是i18n和l10n涉及的不仅仅是语言。
很抱歉继续说下去并总结一下:对于简单的侧边栏,只需自己编写代码即可,没有任何框架,按照自己的想法进行标签替换,大约需要两周时间。但是如果需要更多功能,请仔细考虑你正在做什么。