We have a similar issue in relation to Metadot and i18n but I think it is possible to get round it.

The plan is to allow the user to add various language specific information by rapping it in xml tags and then modifying the display to strip out the non required content on the fly. i.e. <locale lang='en'>English Text</locale>

This is a partial solution and means that in the medium term the content editing side need not be updated significantly. We will probably add that at a later stage but this would require all gizmos to be updated to handle a translation feature which would take time.

We also want to add language dependant templates but this is probably best done by playing with the path to the skins on the fly. Again relatively straight forward.

There are some bits that look like Metadot considered adding i18n but never followed through. Talked to their sales people but they did not seem that interested. Their suggestions were to run either multiple sites with a different skin for each or create multiple sections in the site one for each language.

Both of these require significant user overhead to maintain and make it impossible to create reporting tools that would show article language coverage.

They did mention that they had once done a custom multilingual version for a customer but it used multiple copies of the user entry fields and they have never kept it upto date. Wanted to do some development for us but as we are a perl shop already using LAMP and template toolkit it seemed a bit excessive.

We will initially be implimenting a bilingual site but plan in increase this in future.

UnderMine