Re: Experiences with Metadot?

[fokat]

Dear neilwatson

At $DayJob we evaluated Metadot for a major rewrite of our user-interaction site. It exceeded all of our requirements _except_ being easy to translate/have multilingual sites. While having a content management interface in english is not important to us, the elements you place in the pages are (or were, at the time of the evaluation) not available in spanish.

IMHO, it's not trivial to add i18n as it is. Other than that, performance can be on par with other alternatives based on dynamic pages, depending of course on how many gizmos you put in your pages.

We ended up basing our site in http://www.template-toolkit.org and writing a few Template::Plugin modules (which we will place in the public domain once the rewrite is complete and the code is tested in production).

<plug class="PerlPlug">Please stay away from PHP based CMSes!!! - They're evil and chances are that they will become incompatible with newer releases of PHP.</plug>

[mellsworth]

We are using Metadot and actually having a problem with it.

In October, we did a multiple upgrade -- to RH Enterprise, to Apache 2.0, to Plesk Reloaded control panel (from Ensim), to Persistent Perl, and to the latest version of Metadot. Something broke the file upload capability in the software.

In our investigation we suspect something going on with the handling of the POST of the form that does the upload. Seems that the server times out. The form does not appear to be malformed.

I am actually willing to retain a Perl guru to help us figure out what's going on, so if you're interested, email headguy (at) thewimaxguys.com. We also need someone to help develop and maintain the code in the long run.

Sorry if this is inappropriate in this forum. I'm a n00b here. But I would appreciate any pointers to info or people who can help. And, yes, I've posted on the Metadot forum to no avail.

Thanks for any ideas.

Mike Ellsworth

[UnderMine]

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


Mad implimentation suggestion follows

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