Since the revision ID is used to reference a pane (see https://www.drupal.org/node/2716127), it is not possible to translate non-reusable panes.

When a new translation (using Entity Translation) is created in the FPP admin, a new revision is created. This is a big issue because the pane is referenced through its revision ID on the entity (or Panel page) it was created on.

So the translation is never used as it is attached to a new revision ID.

Moreover, the edit form on the FPP menu becomes useless and leads to misunderstanding for editors, as the changes made there can never be used anywhere, as the revision is fixed and the pane not reusable. So for this case, if using revision ID on a non-reusable pane, the edit form should be replaced by a message telling the user to edit the pane directly in the entity.

Workflow leading to very big trouble:

  1. enable several languages
  2. enable entity translation for panes
  3. create a new pane on a node in the default language (e.g.)
  4. edit this page in the FPP admin, not in the entity
  5. now translate this pane in all language (wonder the time needed for a site in 14 languages)
  6. go back to the entity and switch the language: the translations are not taken in account, only the default language version is displayed...

Does anyone else find a solution for the new behaviour and translations? Did I miss something?

Comments

B-Prod created an issue.

DamienMcKenna’s picture

I have a coworker who built translations onto a site that was using FPP and Panelizer together, I'll see if I can get him to chime in on what they did.

MiroslavBanov’s picture

You can switch to legacy mode in admin/structure/fieldable-panels-panes/settings.
I think this might resolve your problem, but potentially you'll have different set of problems if you use revisions, moderation, reverts to old revision, etc.

Edit: Hm, that's strange. How do you even translate an FPP with entity translation? Never mind.

Pol’s picture

Indeed, switching back to legacy mode fixed the issue.

It's so sad that we cannot fix this with the other option.

DamienMcKenna’s picture

I think the right approach would be to write tests to show what people would like to see happen, then we can work out how to handle that use case.