About raptus.multilanguagefields, Plone 5 and beyond

Plone Support Add-on Development
1

Hello everyone,

we have a large Plone 4 site using Archetypes and are heavily interested in upgrading to Plone 5 (especially in the view of the soon-to-be unsupported Python 2.7). For our multilanguage story we use raptus.multilanguagefields which is strictly dependent on Archetypes and are now thinking about our options with this decision.

We chose this solution, because it keeps the translation within the single object and avoids the trouble of housekeeping which object is the translation of which object, have just one canonical URL, consequently only one catalog entry per object etc. At the time of this decision, it was not clear, that Archetypes is going to be a deprecated technology.

We are pondering about exploring different scenarios from our current situation, namely:

  1. Switching to plone.app.multilingual: This entails a complex migration, with potentially big overhead to keep the local group management the same between the different language folders, potential confusion with our editors, etc.. I also worry about, whether the existing URLs can be correctly remapped to the new ones.

  2. Sticking with raptus.multilanguagefields, but create a Dexterity-friendly version in a community effort or alone from our side. This means to create a clean upgrade path and at least some helpers to alleviate the migration of custom content types.

  3. An other scenario I have not heard of, but fits our needs (translation in one object, small to no overhead for the catalog)?

So I would like to know, if there are other users of raptus.multilanguagefields and what is your strategy to run your multilingual site for the future?

best regards, Paul

2

At Starzel we never used raptus.multilanguagefields because we were worried to be stuck with a solution without a upgrade-path that was not widely used by the community. Also we adopted Dexterity very early.

Your question should first of all be answered by Raptus who maintain the package (it has their name and lives in their github-organization). Maybe they already have plans or other clients with similar problems that could pool their budgets to have them create a version of raptus.multilanguagefields that supports Plone 5+, Dexterity and Python 3. I suggest you give Simon Käser a call since he seems to be the main developer (https://github.com/Raptus/raptus.multilanguagefields/graphs/contributors).

If that turns out to be not a viable option then migrating to p.a.m will your best bet. Creating and maintaining your own multilingual-stack sounds like a recipe for desaster. There are many companies who would love to help you with your migration. And if p.a.m gets improved in the process everyone benefits.

3

I agree with Philip. I'd highly recommend to go with option 1. Moving away from using "the standard" solution is always costly and cumbersome in the long run. This is even more true if the alternative solution heavily monkey-patches the underlying system and messes around with basically all core concepts of Plone:

Even if you would re-implement the functionality on top of Plone 5 and Dexterity (which would require a full rewrite IMHO), you would still be off "the standard" and run into the same issue on the next large upgrade.

If you plan to migrate from Plone 4 to Plone 5 via Transmogrifier (which I would recommend for any larger and highly customized system), the overhead of migrating from raptus.multilinguafields to p.a.multilingual is bearable.

Could you elaborate what problems you expect regarding the local group management? As far as I understand p.a.multilingual, that shouldn't be a problem. Though, @sneridagh (as one of the main authors of p.a.m) is the expert here and might be able to help if you give us a few more details.

Existing URLs can be "preserved" by automatically generate URL redirects during the migration, making sure that all existing URLs continue to work and are properly redirected with a "301" HTTP response to the new URLs. We use this approach for all our larger migrations without any issues.

4

@pgg I think if you would like to find other users of raputs.multilanguagefields you might should ask raptus about that directly, I guess some Swiss Users will have it still in use.

But in the long run I agree with @pbauer and @tisto that moving to the standard solution in Plone for Multilingual Content --> plone.app.multilingual wound be the best way. Plone is to simple in the first place to create own solution, but in the long run it is always better to stay with the community path.

If you mind a blowing catalog, I would always recommend to use an external catalog system like solr or elastic search.

5

Hi Paul,
I agree with @pbauer, @tisto and @loechel. PAM is the way to go. We do not went for a tree based language root folders lightly, there was reasoning behind. For example, Google favors it over other approaches. Having different content over the same URL is not a good idea in SEO terms.

Regarding migration, transmogrifier is the key here. Finding a good pipeline tailored to your use case it's the way to go. Adding it a step that provides some sort of metadata for setup a URL rewriting for redirect old content to the new one would be the best approach.

Regarding your editor users confusion, I would say that having a dedicated tree for each language is the more straightforward and seamless solution to it. Also for readers I always found that having mixed content also confuses people like "how do I see this content now in X when I requested a site in lang Y"?

Cheers,
V.

6

I also agree with others here: use p.a.multilingual. We (CodeSyntax) are users of LinguaPlone and multilingual in almost the 95% of our plone sites and we find it intuitive and easy to explain and teach to the editors and also clear for the visitors and Google.

To migrate existing sites, export the actual site using collective.jsonify abd import using collective.transmogrifier. There are some blueprints to import the content and link it properly using p.a.multilingual.

Mikel

7

Also agree on p.a.multilingual

If your site isn't fully translated and you're looking for a solution to list/show/mix contents from other languages, have a look at https://pypi.org/project/plone.app.multilingualindexes

1 Like
8

Hi all, thank you all guys for responding and giving a new momentum. :slight_smile: We are very grateful for your input and had yesterday an internal discussion about the future of our multilangual story (with no final result yet).

I noticed by your answers, that I should add more pointers to our requirements and shed some light on the (great) features we have with raptus.multilingual and other constraints we have at our site:

  1. It is one single Plone site, that houses the hierarchical institutions of our unversity. There are over 2500 editors with their own separated workspaces. We have almost no original content types and many custom content types. We have two main languages, but this can vary (see point 3).

  2. With the single tree approach of raptus we have all translations in one place. This simplifies the workflow process, because for example all translations of an object can be edited at once. All other actions for an object are synchronized for all languages - this might sound like a huge constraint, but in reality it reduces the workload.

  3. We can have specific language settings at different places within the site. There are two main languages: German and English. At deeper levels in the site it is possible, that there are more languages available and that the default language can switch as well. For example it is even possible, that a third language will be available for an folder A, the next folder, B, has only two and again the next folder, C, has this third language again. I wonder what will happen with PAM at this scenario? For the third language, the structure will look like A->C where as the default ones is A->B->C? What will happen if B gets translated later? I assume, I manually have to move C below B.

  4. Since we have deeply nested structures with different parties involved, there is the need of a fine-grained group management to grant editing or reviewer permissions at specific places. For that purpose we use collective.workspace. Since we have a single tree approach, these group assignments are identical for all languages. With PAM we have to synchronize those assignments across all translations.

Those are main pointers. I can assume, that there others, that would also like a single tree approach, but stick to PAM, because there were no other options with Dexterity.

Regarding your questions/input:

@pbauer, @tisto: We tried contacting raptus, but got no response so far. I am under the impression, that they do not plan to invest much into that add-on. Moving away from the "standard" solution can be indeed costly, but we have also gained many benefits for our editors with the single tree solution.

@tisto:
With multiple trees, we have also separate places where local group assignments are done. Currently, we try to reduce the cognitive load as much as possible for our editors by keeping the known editing concepts the same. Even though we train our editors, we cannot do this in our magnitude and are therefor very carefully with changes of the workflow for editors.

Regarding redirections: The situation is just a bit more delicate, because we have to decide from the desired URL in which language tree we have to jump. But with the Accept-language header at hand, this decision can be made. This problem is now resolved I think. :slight_smile:

@loechel: Raptus' patches for the catalog are not ideal either. Maybe there are no differences at all, but it still needs to determined. For now we use a separate mount point to at least improve the catalog cache.

@sneridagh: Thank you for pointing this out. Google at least can handle crawling those sites with the Accept-language header. Do you have a source for the preferences over the approaches? I think, that p.a.m should more embrace the users, that would like to have mirrored content across the languages. I have already seen tools like cs.linguacopier that copies the contents - but unfortunately I could not find it and reinvented the wheel. The Add-on collective.multilingualtools allows applying the same actions on all language copies, but the last update on Github was 2014.

Regarding the migration: We are already sure, with our many custom types and the switch from Archetypes to Dexterity, that it will be not an easy task. Either with raptus.multilanguagefields or PAM.

regards, Paul

9

Hi Paul,

We are also using raptus.multilanguagefields on a Plone 4 Site for pretty much the same reasons and consequently are facing pretty much the same problems.
Thus, I would be very interested in the decision and experience you made. Did you already migrate your Site to Plone 5?

Thanks and greetings,
Kerstin

10

Hi Kerstin,
due to time constraints and our given project prioritization I was not in the position to give an insightful answer. As of the time of writing, we have not migrated to Plone 5 yet. But we are exploring the situation anew and found the add-on ps.zope.i18nfield, which looks promising for a single tree approach. It offers a language-aware schema field for translations at field level. It also offers text fields and widgets covering already 98% of our use cases for multilingual fields. Also a custom index is provided. Though, to have the very same behavior like raptus, more work has to be put into this. We at TU Dresden are at the testing stage with this add-on and are working right now at a proof of concept. We already improved some minor things here and there. The interesting remaining fields for us are a blob field and image field, which need to properly be cared of.

To outline the way to Plone 6 / Volto I think the next step would be support for plone.restapi (e.g.. JSON (de-)serialization). Then the focus goes to writing the React widget components.

At the Plone Tagung 2020 we also discussed different approaches for integrating plone.app.multilingual providing the same user experience, but at the time try to diminish the most troublesome problems. Once we have a sound comparison between the two approaches, we can decide which is the best for us.

best, Paul

1 Like
11

Do you have some more insight to share regarding a migration away from raptus.multilingualfield?
A naive approach would be to create language folders, duplicate the content and populate it with the language-specific content from the original content object.

12

This is indeed the migration story when migrating from raptus.multilingualfield to plone.app.multilingual. Additionally, if raptus.multilanguageurls is installed, it should be possible to even provide more fitting ids in the language-specific trees. Each translated object is then properly linked via the translation manager.

The downside is that the blob data is possibly growing by the factor of languages (unless the implementation is clever enough to detect duplicates). This may or may be not be relevant for client, if the site is very small and/or there is plenty disk space.