[Framework-Team] Discussion about multilingual

[Ramon Navarro Bosch]

There are some issues I would like to discuss with FWT before pushing
forward the PLIP that involved which kind of site we want and some
considerations about technical implementation.

On multilingual stories there are two different aproaches that fits on
Plone :

* A site were you can have a language where there is only few content
translated and you want to get the original objects when you are browsing
in case it's not translated. This use case is commonly asked for small
sites, where they plan to have a home page in all the possible languages
but the rest of the site is in less languages.

* A site were you have a  language root folder (LRF), ('/en/') and you
browser on that language. Inside on LRF you only see content on that
language, so it's not possible to have content from other languages that
are stored on it. This use case is commonly asked for medium, big sites
where they plan the information that is shown on each language and take
care that the information that is shown is correct on that language.

Both scenarios are incompatible in my opinion. I tried to figure out how to
deal with them on the same multilingual solution but leads me crazy because
of the implementation details. Without hacking the catalog search the first
solution should store the translations on the same object and have only one
object for each content. There is only on content tree for all languages
and you can get the field on the correct language depending the preferred
language. The second scenario is much more cleaner, easy to maintain and
more w3c URI friendly. It's the actual behavior of p.a.m.

There is a possible aproach for both of them, patching the catalog and
using the same solution as LinguaPlone. The problem on that solution is
that folders that are translated were splitting the content and you can end
with a mess of translations that makes difficult to maintain.

Our idea, when we thought about pam, is to create something that don't does
pain in the head when you use it, so all the content that is in English on
the /en/ folder and linked. Without any patch, seeing always all the
content that's on the site and easy to maintain. That's the solution I
would like for Plone, but that is not compatible with a site with some
content translated.

There is another option ( my second question ): shared content. Some months
ago I've talk with Martin about collective.alias. It's really one the
biggest hacks I've ever seen and does some kind of magic that shouldn't be
used on any production site. Besides that I've looked for a solution that
enables that kind of behavior and finally implemented a proof of concept
that I would like to get some feedback. You have a LRF and the site root by
itself, what is in the site root folder is published also on all the LRF
enabling to have ordered shared content on all languages. We created a DX
content type that has an implementation of the BTreeFolder API, it gets the
content from the root and shows as own. That leads to some problems:

* UUID : in order to catalog the object inside the LRF with a different
UUID than the object on root we created an adaptar that adds the language
on the UUID.

* In case you have 40 languages and one document on the root you
automaticly get 40 objects more one x language increassing the catalog
really fast.

* It makes possible to have on each LRF a control panel, as we are pushing
all the content from the root we also get the tools, and registers,
enabling a option to create "subsites" inside each LRF ( we also added
IPloneSiteRoot in order to test that all configuration views work ). That
makes a great look feel for the user as it get the configuration panel with
the browser navigation with the same language as it's browsing.

This solution is much simpler that collective.alias and easier to maintain,
but doesn't allow to define on which language do you want the shared object.

A multilingual solution should be going OOTB with plone but not installed,
so I would like that the quality of the solution is as great and easy to
maintain than the rest of plone. That's the reason I'm asking some feedback!


Ramon



-- 
Ramon a.k.a bloodbare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20130812/ffc5e1a3/attachment.html>