PHP translation frontend similar to Rosetta?

Question

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.

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.

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?

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

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

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.

Answer 1

If you can use gettext files (Zend_Translate supports them) you can give POEdit a try. It is quite simple to use and supports plural forms since version 1.3.

However, users will have to download the files and reupload them in the end, because POEdit is not an online tool. I don't know any other web based tool.

Answer 2

You can try Transtable, a simple web intefece for editing translations in php arrays.

Answer 3

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.

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.

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.

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.

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).

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.

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.

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

• 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.

• Semitic language run right to left

• Japanese and other language that are not alphabet based can run ltr rtl top to bottom and some do not even have white space
• dates? US, Japanese, UK, Hungarian as all different
• currency and number formats, don't even start me off

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.