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 :

1. 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).
2. 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 :

1. Make your archetype extenders to make your wanted fields translatable, example can be found here
2. register your extenders in setuphandlers (Generic Setup import step), example here
3. 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.

Important :

• 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

Since Plone base properties style could seems too rich for a standard use case, phantasy skin edit forms could be also too complex.

When i saw how easy it is to change some skin properties in a blog system like word press ( …),  i thought we need the same feature in Plone.

Collective Phantasy is done for that.

Building a new skin product with a standard static theme and a customized skin schema is something you can do easily with collective phantasy.

If you want an example, just test the « 3 colors theme » plone product.

In your buildout :

in instance eggs section add :

    collective.threecolorstheme

in zcml section add :

    collective.threecolorstheme
    collective.threecolorstheme-overrides

Relaunch your buildout.
Launch your zope instance.

In plone_control_panel you will get :

Check for « Three Colors Theme » Product, this will install the product and its dependencies :

Go back to the home page, of course the « static » theme has changed (my poor contribution to plone themes community)

We want to change the dynamic properties, so we click on « Contents » tab, and we can see that everybody is here : the dynamic root skin for portal, and the phantasy skins repository (read previous posts …) :

We want to build a new skin, so as we have seen in previous posts, in phantasy skins repository we add a new skin :

In this form you could see differences with a classic phantasy skin form (for developpers/integrators look at the code it’s just some easy Archetypes bidouille) :

- 3 colors only + mutators to change all colors

- an entire fieldset removed

- many fields unuseful in this theme are hidden

- some skin attributes added in schema

Go back to reality : just change some colors

Now we will import a skin sample provided in « three colors theme product ».

In alternate_skin folder you will find a zip file and a txt file (howtouseit.txt).

Click on « import images and files », choose the alternate_skin.zip file

Read howtouseit.txt and change some colors or properties

Use plone kss power to change images’ names quickly

CTRL-F5 to refresh the page, of course you need some design feeling to understand what’s happen here, but it’s not so complicated (…)

In the product you will find another example with another howtouseit.txt, here, then just add a folder and choose the good phantasy skin and you will get :

Loving Plone

When installing collective phantasy it will takes its skin properties from the current available plone theme.

You could see in screenshots below a customization of qPloneSkinWhiteBlack plone theme, using phantasy :

Today we will work on skinning Plone, you will see how easy it is, especially when using collective.phantasy.

This product is only plone3.1.x (and perhaps ++) compliant.

I suppose you know how to build a new plone instance using buildout. I know it’s not always so easy for Windows users, but keep cool, read documentations about buildout (it’s a really powerful feature), and send a comment here if you get problems with this question, i will try to help you .

So, in your plone3.1.x buildout.cfg, just add these two lines : In instance – eggs sections :

    collective.phantasy

In instance -zcml section :

    collective.phantasy

Now you could launch your buildout :

    bin/buildout -vvv

Then launch your Plone instance.

    bin/instance start

OK.

Install collective.phantasy in Plone

Go on your plone site > Add/Remove Products You will get this screen :

Check for « Collective Phantasy » product and Save the form.

This will install « Collective Phantasy » product and its dependency « Smart Color Widget » :

The portal look is changed, but it’s just an example, not the best wonderful design ever seen ,
so we will change it.

Change the portal skin

Go to your portal root, click on Contents :

You will get two new items :

- An Item called « Phantasy Skin repository », it’s a folder containing alternate skins for folders

- An item called « Plone’s logo, colors and border defaults », it’s the dynamic skin used for your portal, you can delete it and recreate it, but now we will just change it click on this item,
then click on « edit » tab

Click on « Colors » tab, change the background color value for « #f3f3fb » :

And save the form, here is the result :

Re-click on edit tabs, then on « dimensions » tab,

change the values for ‘portal width’ and « Portal horizontal position » like this :

And save the form :

hmm it’s better but we will do some new things.

First we will add our logo.

Go back to your skin, use the contextual menu : « Add new… », choose « Skin Image » :

Click on Browse (« Parcourir » in french ), choose your logo image on your HD :

Save the form. Go Back to your skin.

We will change the logo name in skin. Click on edit tab, then on « images » sub-tab.

Change the logo name value for « logo.gif » (the image id you’ve just uploaded), and save the form.

Here is the result :

Go back to your portal home page and refresh the page, CTRL-F5. If you want to see the left column as shown in next image you also need to change the portlet navigation property with « Manage portlets » …) :

Setting a new skin and choose this skin for a particular folder

See global tabs at top, Click on « Folder with other skin »

You see that the portal look is changed here. Ok. Go back to the Phantasy Skins Repository, click on Contents, you see here alternate skins which can be used by any folder :

Click on the only skin present here :

Oh, oh … the same look as we’ve seen somewhere before.

OK, now we will change everything, go back to the portal root > Contents tab, select the dynamic root skin and click on « copy ». :

Go back to the Phantasy Skins Repository, and click on « Paste » :

We will rename this skin, it could be practice, check the second skin and click on « rename » :

Then click on this skin to go on it. Now we will do always the same thing, click on « edit » and change background color, but take care because now the color value must cohabit with a future background image (use Firebug extension to help you) :

Create a css for your skin

Now we will do something special that’s not embed in Phantasy skin parameters. Edit a text file, save it on your HD as a a css file, here we call it « ornicat.css », we add a little new selector in this css, this selector add

a large left violet border to the page :

Create some images used by your skin

We create a global background image which can cohabit with the background color, using Photoshop or any picture dedicated software (we save it on local disk as « portal-background.gif ») :

We create a new logo with the same software (we save it as « logo-2.gif ») :

Post all these files in your skin

Create a zip archive with the 3 precedent files :

Go back to your browser, to your site and to your skin, click on « Import images and files » :

Click on « browse », choose your zip file on your local disk.

Click on import, wait during upload …

Upload is done

Setting up your special skin

Click on « Edit » tab, enter the css file id (ornicart.css here)

Click on « images » sub tab

- Change the logo name for the new logo id (logo-2.gif)

- add a body background image name with your background image id posted first (portal-background.jpg)

- change background image position for « Top right »

- change background image repeat for « Vertcal repeat »

- Save the form

Here is the result

Ah, i think it’s better

Give a folder a new skin

Go to « Folder with another skin », click on Edit, Below Phantasy skin, click on « Add », now you can browse the site for a new skin, Choose the « Alternate skin » we’ve made before.

Save the form Click on CTRL-F5 to refresh the page.

Now you can say « Skinning Plone is not so complex ».

You are in the « sein des saints » of plone and buildout, and you know how to do a buildout on windows (congratulations), so i wont tell more about this. But if unfortunately, you need a buildout on Windows VISTA, you must patch your MingW installation (only for MingW 3.4.5) :

http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz

Unzip and replace all files in your MingW 3.4.5 folder

Otherwise you will get many buildout errors, oeuf corse.