Photo: Projjwal Pohland .

In Linguaplone, the one thing that you can’t translate is the portal itself. Hence if you have any documents or folders at site root, then they will be translated into documents or folders also at site root. It is easy to see how (especially with more than two languages) things can get very messy indeed.

However there is a way around this if you have your site address directed to a folder at the root of the portal, public_home, say (in my opinion this should be Plone default behaviour to stop user content from being scattered around portal tools in the zmi). You can then translate the folder and the translated folder will show up on the same level as public_home. (You can even translate some content inside the folder before you translate the folder and LinguaPlone will put the content inside the folder for you)

However, perhaps you want all content – including translations – to be inside the public_home folder for ease of maintenance. Well, after you translate the folder, you can go into the zmi, cut the folder and paste it within public_home. This doesn’t seem to have any effect on the links between original and translated folders, or on any content translated after you move the folder, and you now have all the content for each language inside their respective folders inside public_home.

This promises to be a very useful tool for webmasters of large sites or sites with many users. Sure, one could always check broken links using server states, but by having a link checking mechanism in the UI you can let each user in a multi-user site be responsible for keeping their own section 404-free.

The CMFlinkchecker program comes in two parts; the user interface (CMFLinkchecker) and the bit that actually crawls the site (LMS). These are distributed as two seperate programs. You can however, just install CMFLinkChecker and then go to ‘link management’ in plone preferences panel and register your website to access LMS on a server kindly provided by the authors somewhere over in Germany. After a couple of goes (the server might have benn down) I eventually got through and was given an id and password via email to enter in the ‘link monitoring server fields’ in the aforementioned ‘link management’ page. After that, I srolled down to the bottom of the page, hit ‘crawl my site for all links’, and got the ball rolling….

For a small site (around 200 links), about 20% of the links were evalusted straight away, the rest were queued up on the server and were ready the next time I logged in. The process probably goes a lot faster if you have LMS installed on your own server.

LinguaPlone is the standard multilingual translation solution for Plone, and is used to generate translations of websites like Oxfam .

Upon first hearing of LinguaPlone, I was expecting a scenario where the whole page – page body, tabs, portlets, the lot – would obediently translate given the necessary words and a couple of clicks of the mouse. Then again, the open source community was not made for demanding types like me who expects everything without putting in some spadework himself (I am only making my first forays into Python now…:) )

What LinguaPlone offers (so far) is a very easy way to translate the page body. Simply choose what languages you are going to have your site in in Preferences (they are pretty much all there), do up a page in your default language, and access the ‘translate’ tab at the top of the document to translate into the language of your choice. In addition, uninstalling Linguaplone doesn’t affect this translated content, it only removes the links between the different translations, which can be restored by reinstalling the product.

All the same, it’s a little hard to know if LinguaPlone offers all that much more convenience and functionality over manually creating new content for each language yourself. I’m sure it does, else it would not be so widely used, but the lack of decent documentation doesnt help much to illumine me. For example, a cool thing would be if LinguaPlone used the IP address of your computer to automatically serve you up the content in your own language – its a rather intuitive thing and one might reasonably expect a multilingual solution to have this facility. It’s not an easy thing to test (unless you have access to a private plane), and so I dont really know if it does this…..

(If my interest in Linguaplone persists over the next couple of months, I promise I will document answers as I find them here)

One thing that would really enhance LinguaPlone, in my view, is if translated objects could inherit the properties of the original object. Perhaps I want to use a couple of portlets in left_slots: in current LinguaPlone, I put the portlets in for a page, but they are not there for their translated counterpart. Not everyone will want this of course, but it would be nice if it were included as an option, along with an option to automatically update translation properties if the default properties are changed. Perhaps all the contents of the ZMI properties tab could even be displayed in the 2-column ‘translate’ page, and the user could pick which ones he wants to keep.

The top navigation bar tabs are a known issue with Plone multilingual sites, but if property inheritance were allowed the subsite feature of our vsCore product could then be enabled for those sites whose tabs bear the names of the content they point to.

With Plone Form mailer, you can design email forms through the web. We at Vasudeva Server have had occasion to use them a lot.

Their best point is the ease with which you can actually get a form drummed up and ready on your site. The ‘edit’ tab lets you enter text before and after the form, configure who to send it to, sort out what the email is going to look like, and design a ‘thank-you’ page. The ‘modify form(zmi)’ tab lets you work on the form itself.

The edit tab

The fields to enter in the ‘edit’ tab are pretty intuitive (and have
been made more so in recent versions). There are a couple of times
where you have to enter a TALES expression, like the mail recipient or
the email address of recipient. For example, if your name is Mr Happy
and your email address is happy@happy.com then enter string:Mr Happy and string:happy@happy.com in the relevant fields. One nice feature is they warn you what bits not to touch if you haven’t a clue what youre doing!

The ‘modify form’ tab
By default, the form has a field for name, email and message. One
recent improvement to Plone Form mailer is that the whole form doesnt
fall apart if for some reason you delete the email field. Clicking on
the tab takes you to a ZMI interface where you can see a menu
containing each of the fields. You can add more fields by clicking on
the top right, including checkboxes, radiofields, you name it.

Issues
Sometimes we have had problems implementing PloneFormMailer using
scripts other than Roman (eg Cyrillic). Sometimes the checkboxes dont
work and the characters are not correctly interpreted in the email.

One issue is that form mailers invariably always present problems when migrating Plone, and usually have to be deleted and recreated again. However PloneFormMailer is quite young and we would expect this to be sorted out in the future.

You can read more about Plone Form Mailer on their section  of  the Plone site