PHP翻译前端类似于Rosetta?

Pek*_*ica 26 php translation zend-framework gettext internationalization

我目前正在将Web应用程序从基于数据库的国际化方法(每个单词在翻译表中有一个条目,以及实际翻译)迁移到基于Zend_Translate和CSV文件的方法.

我需要提供一种最终用户友好的方式来快速轻松地更新这些翻译.理想情况下,为了最大限度地降低破坏内容的风险,用户不会直接编辑CSV文件,而是显示带有字段的漂亮表单.

您是否知道一个独立的,基于PHP的,最终用户兼容的转换前端,它支持其中一个适配器Zend_Translate必须提供 - 理想情况下是gettext或csv?

像Python的/ Django的Rosetta, 但在PHP?Rosetta正是我所需要的:

在此输入图像描述

但出于服务器设置原因,我非常希望继续使用PHP.

SimplePO看起来正朝着正确的方向发展,但过于简单 - 它似乎无法处理多种语言和目录以及复数形式.

Pur*_*lot 22

我还没有看到另一个,可能是由于以下原因.尽管它在SimplePO网站上所说的内容,但翻译人员并不喜欢并且通常不会在如上所示的并排翻译系统上工作.

这就是程序员想象翻译人员会如何工作而且存在缺陷.翻译人员使用名为TMX的工具包,翻译记忆库交换(通用名称参见Okapi,一个开源实现来感受它),并在其中构建单词,短语和句子的翻译词典.他们采用不同格式的文件并将其提供给TMX软件,这为他们提供了60%,70%等翻译的第一遍,但是就像目标语言中有意义的谷歌语言API一样可怕.

然后他们所做的就是翻译TMX未处理的词,添加到逻辑词典中,并将它们俗称化,即使其在目标语言中工作并理解它.出于这个原因,译者应该始终翻译成他们的母语.

他们这样做的原因有很多,a)它有意义和有效,减少了他们的工作量b)因为他们通过这个词获得报酬并且做并排翻译不允许他们使用他们的工具并最大化他们的收入.

翻译者想要的是一种文件,您可以导出一种格式,他们可以导入和翻译,导出并发送给您进行导入.

文件格式可以是csv,rtf,tmx,xliff,gettext,如果你阅读Symfony框架文档,你可以看到他们是如何做到并处理它的(他们在我看来做得很好).

大约8年前,当我不得不用英语,法语,德语,匈牙利语和斯洛伐克语写一个网站时,我说的一切都处于类似的位置,我和SimplPO做了同样的事情,只是写了我自己的并排应用程序,允许这样做完成.然而,我们编写应用程序的公司在内部进行了所有自己的翻译,因此我们没有遇到翻译问题.当我们这样做时,我们写了一个导出到RTF并从RTF导入(这本身就令人难以置信),所以翻译人员可以如上所述运行.

然而,SimplePO是我见过的唯一其他实现的想法.像Zend这样的框架似乎认为你只需要创建查找标签来替换单词和短语,并且不构建对应用程序的控制来管理进程.因此很快就会失控,维护它变得既困难又昂贵.

写多语言网站的大多数人实际上并没有这样做.他们编写一个主站点,然后复制,翻译并维护翻译版本.它对我们的逻辑类型似乎很笨拙但实际上非常有效.

它有效的原因之一是i18n和l10n与语言有很多其他的东西.

  • 外观和感觉.Anglo saxons喜欢冷色调和san serif字体,西班牙裔人喜欢Serif类型的面孔和更明亮的颜色.当你跨越其他文化时,对布局,类型,颜色等的期望变化很大.
  • 法语和某种程度上德语比同等英语长30%,更冗长,所以你的布局很快就会在手提篮中下地狱.

  • 闪米特语言从右到左

  • 日语和其他不是基于字母的语言可以从上到下运行ltr rtl,有些甚至没有空格
  • 日期?美国,日本,英国,匈牙利都不同
  • 货币和数字格式,甚至没有启动我

很抱歉接下来总结一下: - 对于简单的并排只是自己写的,我花了大约两个星期没有任何框架并且正在努力,因为我只是使用标签替换.但是更多,并考虑你在做什么.小心.

  • TOP-NOTCH POST.+1 (4认同)

Mar*_*rre 2

如果您可以使用 gettext 文件(Zend_Translate 支持它们),您可以尝试一下POEdit 。从 1.3 版本开始,它使用起来非常简单,并且支持复数形式。

然而,用户最终必须下载文件并重新上传,因为 POEdit 不是在线工具。我不知道任何其他基于网络的工具。