Plone and multilingual sites
Usually we build multilingual Plone sites with LinguaPlone.
This solution has a big advantage, it’s generic and very easy to implement in a plone site.
But there are many inconvenients, due to the design of this product (translations are independent by design) :
- Each translation is a new Archetype object, and it could be a big problem on sites with many contents, the portal objects number is increased by the number of available languages.
- Translations uses plone references catalog to be linked to the original (called canonical) object, but when moving objects translations are not moved, when copying pasting objects, translations are not pasted, when deleting objects translations are not deleted, when reordering contents, translations are not reordered, when publishing objects translations are not published, … For web masters maintaining a site with LinguaPlone inside could be a challenge.
- When translating folders with LP, all translated contents are moved from the canonical folder to the translated folder with same language, translating low level folders on big depth tree sites could take a long long time, don’t be surprise if you get errors.
- If a content is neutral (with no language attribute), inside a translated folder, it could not be seen when browsing a translation of the parent folder.
- At last a lower problem : the translation edit forms are not pretty to use, they show a table with two columns, the first column with the « canonical » content inside in « view » mode, the second column with the translation edit form, in fixed width sites the translated form width is sometimes ridiculously small.
But since many years we use LinguaPlone because it was the only easy way to make multilingual Plone sites.
By the past we were using a LP patch called LinguaFace to reduce the number of problems with LP (synchronisation on reorder, copy-paste, delete, or move – see neutral contents inside all translated folders – more usable translation edit forms …), but LF add a new layer of complexity and maintaining it with all LP versions becomes complicated. See some examples on how it works :
- when a content is copied, all translations are copied
- when a content is pasted or moved all translations are pasted or moved at the good place (not so easy)
- when a content is published or retracted translations follow the same workflow transition
- when a folder is translated, we don’t see only objects inside but also objects with same canonical Path (a new catalog index) to see also neutral contents.
- Navtree is patched, breadcrumbs are patched, to use canonical path
- and so on …
A big nightmare.
To day a new solution exists that store translations inside each Archetypes field, raptus.multilingualfields, and a Plone integration of raptus.multilanguagefields called raptus.multilingualplone that extends the schema of all Plone Content Types making them translatable. raptus.multilingualfields also provides multilingual catalog indexes that return the good translated data when searching for contents or displaying trees, and multilingual criterions for topics.
A LP feature not provided by raptus.multilingualfields is the internationalization of urls, if you really need this feature, i think it’s not a big challenge to add some traversal rules, for me it’s not essential.
AnotherLP feature that can’t be provided when storing translations in fields is to get different workflows or security settings for each translation. If you need this feature use LinguaPlone, LinguaPlone is done for that, it makes all translated contents independent, but i’m curious to know the number of users who really want this feature, all clients i had never ask for that but finally, after some LP experience, always wanted the exact opposite use-case.
To make your Plone site translatable with raptus.multilanguagefields, you have two choices :
- Add raptus.multilanguageplone in your buildout and install it in your Plone Site using extensions products control panel, to make all your Plone content types and derived translatable (all fields for which translation make a sense are translatable).
- I prefer integrate by myself raptus.multilanguagefields inside a product, since we could want just some fields or content types translatable, as example i don’t need to translate the images or the files contents, just their titles and descriptions.
How to implement the second solution ?
Just take a look at raptus.multilanguageplone code, it’s easy :
- Make your archetype extenders to make your wanted fields translatable, example can be found here
- register your extenders in setuphandlers (Generic Setup import step), example here
- replace the standard catalog indexes with multilingual indexes in Generic Setup profile, example here
That’s all, you will get superb edit forms with translatable fields inside, you also will get a google help to translate contents (a pleasant gadget). I say « Bravo » to raptus developpers.
- these products are young, and there’s still many work todo to make it work without problems (tests are needed …). Last 0.6 releases have bugs under plone3.3, use the svn versions below instead.
- raptus.multilanguageplone 0.6 has a bug in extenders with primary fields, tested in Plone 3.3 (fixed in branch aws_evols, not tested with images at this time)
- raptus.multilanguagefields 0.6 has a bug, doctests are broken in Plone3.3 (fixed in trunk )
- At this time these products don’t have unit tests or functional tests, it’s the only reproach i can make. I started the work here, and here