I'm sorry in advance for this lengthy article about improving plone.app.multilingual.
In the end I don't know, whether this should be a PLIP or maybe just a discussion.
Either way, here we go:
While plone.app.multilingual offers a great way for building sites with individually curated language versions (probably with a dedicated editor team per language), it does not necessarily suit well for everyone. For example when building a site where each page which needs to be represented in different languages - with editors not changed and where content structure does not change per language necessarily either.
Other CMSes like TYPO3 or Neos have suitable solutions for different multilingual approaches in form of single- and multi-tree modes, whereas Plone offers only one solution for building (multi-tree) multilingual sites.
Now, building a single-tree solution from scatch is a totally different beast and I understand, that pursuing that way will bear lots of risks. Therefor I would like to focus at first on a solution which is built upon plone.app.multilingual to make the world better for everyone.
So the main nagging points for us on the current state of plone.app.multilingual are:
- When an editor wants to build a mirrored site and creates content with its translations, the editing process should be as easy as possible - that means skipping tedious linking of translations, managing workflows for individual objects, keeping synchronized permissions. The whole process to keep everything the same demands much attention from the editor.
- The lack of support to allow local language settings in a deeper level of the site. There might be parts of the site that offer new languages, which are not necessarily available at the whole site.
- Even with allowing all possible languages from the root, creating a new translations from an existing object will create a new object in the root folder with no relation to its parent object. This eventually leads to a mess, where the structure is lost, unless one replicates/translates each container one by one from root to the current object.
- Managing resources at places other than root. We established at our site the concept of resource folders, that collects the available resources (images, files, etc.) to the respective group - with different permission settings. While plone.app.multilingual offers a singular language independent resource folder in the root, this is not sufficient in a scale of many different editor groups.
To make things constructive, I would like to share a possible solution and I would appreciate your feedback, whether you consider this attempt to be suitable for the aforementioned problems or to be just not worth for further elaboration.
Think of this as an orthogonal workflow to the usual publication workflows, which allows to synchronize the state of objects across all languages.
In terms of plone.app.multilingual. this would mean that all objects within a translation group (i.e. one object and its translations) have synchronized actions like
- Workflow actions Like publishing, submit, retract ..
- Adding/Pasting/Moving/Deleting objects
- Specialized actions like adding/remove persons in collective.workspace
to be applied on all language trees. The last point is especially important in order to have the very same permission situation in the respective language tree.
There is already one add-on collective.multilingualtools that would allow this for some actions.
Combining those actions might take proportionally longer with an increasing number of languages, but might be off-loaded with asynchronous tasks in the background to ease loading time.
Special content in language trees
One still can create content for a language-exclusive audience by disabling synchronization for an container/item.
When a container is not synchronized, all its children are also not synchronized.
The editor is then responsible to manually link translations if needed, but that is in the end the default editor experience with plone.app.multilingual.
Local language settings
By default language settings are coupled with the Plone site. There are add-ons like ftw.subsite or collective.lineage to mimic a Plone site, that probably could work to achieve local language settings, but this is yet to explored. In one thread it is being said, that there might problems with plone.app.multilingual and collective.lineage.
Another approach could be to make the language utility context-specific, where the hierarchy could be checked, if any object offers local language settings. But that would require probably many changes in the core.
Place holder objects
The idea of place holders are to solve the problem of losing the original hierarchy in the different language trees, which happens, when one translate an object without translating all its ancestor objects before.
One idea discussed at the Plone Tagung 2020 in Dresden (with @fredvd et al) was be to automatically create these ancestor objects, when creating a new object/translation. This is done by cloning the counter-part from the main-language, ideally with the language-specific id, and labeling them explicitly as place holder.
Place holders will not be offered as available translation for the end user, but can be used by the editor, once the language is available in the respective level. Place holders are also synchronized with their original object, making it easier later to pick them off and finish the full translation.
Risks / Open issues
At the time of writing I am afraid to see risks both in terms of maintainability and scalability.
To allow working with synchronous actions, the language versions must to be perfectly in sync. If one language version is out of sync, the whole action is turned futile. This might easily happen, when one object is locked. I am not sure if this level of synchronization can be held in the long term.
The idea of copying an object and labeling it as place-holder also seems to be quite expensive compared to the benefit (restored structure, correct permission settings).
Maybe there are some more efficient solutions with a smaller memory-footprint?
Attempting to implement these ideas is a potentially big endeavour and I therefor would like to hear your feedback. Maybe you do see other ways to improve the way plone.app.multilingual. in order to deal with the mirrored site approach?
Edit: I redacted my texts and retracted the idea of the common/cross-lingual view on resource folders.