Hi all, thank you all guys for responding and giving a new momentum. 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:
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).
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.
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.
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.
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.
@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.