PHP翻译前端类似于Rosetta吗? [英] PHP translation frontend similar to Rosetta?

问题描述

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

I'm currently migrating a web application from a database-based internationalization approach (each word having an entry in the translation table, and the actual translation) to one based on Zend_Translate and CSV files.

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

I need to provide a end-user friendly way to update those translations quickly and easily. Ideally, to minimize the risk of breaking stuff, users would not edit the CSV files directly, but be shown a nice form with fields.

您知道一个独立的，基于PHP的，最终用户兼容的翻译前端，它支持Zend_Translate所提供的一种适配器吗?理想情况下是gettext或csv?

Do you know a standalone, PHP-based, end-user compatible translation frontend that supports one of the adapters Zend_Translate has to offer - ideally gettext or csv?

类似于Python/Django的 Rosetta ，但在PHP中呢?罗塞塔恰好满足了我的需求:

Something like Python's/Django's Rosetta but in PHP? Rosetta does exactly what I need:

但是出于服务器设置的原因，我非常想在这里使用PHP.

but I would very much like to stay with PHP here for server setup reasons.

SimplePO 看起来像是朝着正确的方向发展，但它太简单了-它没有似乎无法处理多种语言和目录以及复数形式.

SimplePO looks like it goes in the right direction, but is too simple - it doesn't seem to be able to handle multiple languages and catalogs, and plurals.

推荐答案

我没有看到另一个，可能是由于以下原因.尽管在SimplePO网站上说了什么，但翻译者并不喜欢并且通常无法像上面所示那样并排使用翻译系统.

I have not seen another one and probably for the following reason. In spite of what it says on the SimplePO web site translators do not like and often will not work on side by side translation systems as shown above.

这就是程序员认为翻译人员可以工作的方式，这是有缺陷的.译者使用称为TMX的工具包，即翻译记忆库交换(通用名称，请参见Okapi，这是一种开放源代码实现，可以使您有一种感觉)，并以此建立单词，词组和句子的翻译词典.他们采用不同格式的文件，并将其输入到TMX软件中，这使他们的初次通过率是60％，70％等，但是就像Google语言API一样，在目标语言的意义上受到了严重破坏.

That is how programmers imagine translators will work and it is flawed. Translators work with a toolkit called TMX, Translation Memory Exchange (generic name see Okapi an open source implementation to get a feel for it), and in this they build up translation dictionaries for words, phrases and sentences. They the take a file of varying formats and feed it into the TMX software, this gives them a first pass that is 60%, 70% etc translated but like Google language API horribly mangled in terms of making sense in the target language.

然后他们要做的是翻译TMX未处理的单词，将其添加到符合逻辑的词典中，然后口语化它们，即使其在目标语言中起作用并使其有意义.因此，翻译人员应始终将其翻译成母语.

Then what they do is translate the words not dealt with by TMX, adding to the dictionaries where logical, and they colloquialise it, i.e. make it work in the target language and make sense of it. For this reason the translator should always be translating into their native language.

之所以这样做是出于多种原因，a)有意义并且行之有效，并减轻了工作量； b)因为他们得到了单词的报酬，并肩并肩翻译，不允许他们使用他们的语言.工具并最大化他们的收入.

They do it this way for a number of reasons, a) it makes sense and works and reduces their work load and b) because they get paid by the word and to do side by side translation does not allow them to use their tools and maximise their income.

翻译人员想要的是一种可以导出的文件格式，他们可以导入和翻译，导出并发回给您进行导入.

What translators want is a file in a format that you can export, they can import and translate, export and send back to you to import.

文件格式可以是csv，rtf，tmx，xliff，gettext，如果您阅读Symfony框架文档，则可以看到它们的处理方式(我认为它们做得很好).

The files formats can be csv, rtf, tmx, xliff, gettext and if you read the Symfony framework docs you can see how they do it and handle it (they do a pretty good job in my opinion).

大约8年前，我不得不以英文，法文，德文，匈牙利文和斯洛伐克文写一个网站时，我处于类似的位置，我做的和SimplPO一样，只是简单地写了我自己的并发申请给允许这样做.但是，我们正在为其编写应用程序的公司内部进行了所有自己的翻译，因此我们没有遇到翻译人员的问题.当我们做完这些之后，我们写了一个到RTF的导出和一个从RTF导入(这本身就是令人难以置信的)，所以翻译器可以像上面那样工作.

Having said all that i was in a similar position about 8 years ago when having to write a site in English, French, German, Hungarian and Slovakian and i did the same as SimplPO and simply wrote my own side by side application to allow this to be done. However the company we were writing the application for did all their own translation in house so we didn't hit the problem with translators. When we did we wrote an export to RTF and import from RTF (that in itself is mind boggling) so the translators could function as above.

但是，SimplePO是我所见过的想法的唯一其他实现. Zend之类的框架似乎认为您只是创建查找标签来替换单词和短语，而没有在应用程序中建立任何控件来管理流程.因此，它很快就失控了，并且维护变得既困难又昂贵.

However SimplePO is the only other implementation of the idea i have seen. The frameworks such as Zend seem to think you just create lookup tags to replace words and phrases and build no control into the application to manage the process. Consequently it soon gets out of hand and the maintenance of it becomes both difficult and expensive.

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

Most people who write multilingual web sites actually don't. They write a master site and then make a copy, translate it and maintain the translated version. It seems clunky to us logical types but is actually very effective.

之所以有效，原因之一是i18n和l10n与语言无关.

One of the reasons it is effective is the i18n and l10n are about many other things than language.

• 外观.盎格鲁撒克逊人喜欢冷色和San Serif字体，西班牙裔人喜欢Serif字体和较亮的颜色.当您跨越其他文化时，期望在布局，类型，颜色等方面也千差万别.

• 法语在某种程度上比等效的英语长30％，更冗长，因此您可以快速地将其放置在手提篮中.

• Look and feel. Anglo saxons like cool colours and san serif typefaces, Hispanic peoples like Serif type faces and brighter colours. And as you cross other cultures the expectations vary wildly in layout, types, colours etc.

• French and to some degree German is 30% longer, more verbose, than the equivalent English so you layout goes to hell in a hand basket real quick.

犹太语言从右到左

很抱歉，继续进行总结:-为了简单易行，请自己编写，花了我大约两个星期的时间，没有任何框架，并且在我继续进行过程中解决了这个问题，只是使用了标签替换.但是，再考虑一下您在做什么.小心点.

Well sorry to go on and to summarise:- For simple side to side just write it yourself, took me about two weeks without any frameworks and working it out as i went along just use tag replacement. But any more and consider what you are doing. Carefully.

这篇关于PHP翻译前端类似于Rosetta吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！