Entity translation support for Drupal 7

EDIT: Misread description. Disregard.

note that we are pushing a well supported translation status in D8 at issue:
#2414913: Support entity translation of paragraphs
With diff support
#2433099: Provide a custom diff plugin

including a tmgmt integration...
#2462263: Support paragraphs translation.

Hope you're not going a completely different route here.

@miro_dietiker: i'm currently porting a field_collection entity translation patch to paragraphs (or at least trying to). I'm currently online in #drupal and #drupal-support - might be a good chance to put our heads together.
Edit: 7.x in my case.

@ciss i'll be at montpellier / Dev Days, personally only wed-sun. Until then we try to make all relevant pieces of D8 Paragraphs translation including its TMGMT integration ready. During easter weekend i doubt you will find me in IRC.

I'm looking after a solution for scenario B.
As Jason Dean said in #2388185: Fully support Entity Translation:

User creates an English node, and adds paragraphs: image gallery, text, video, text. Then she creates a Spanish translation of the node, and image and video paragraphs don't need to be translatable as they will be the same. But she would like to translate the two text paragraphs somewhere in the backend.

This is exactly the kind of behavior I need for most of my clients: if we're editing a node with a paragraph field in language A, the paragraph field widget is showing the paragraph item entity in language A. If in language B the paragraph item entity is shown with language B.
Should we have a different issue for this scenario?

@miro_dietiker, any progress on this? Any chance the D8 solution can be back ported to D7?

Any news about this topic ? It is important that this module can be work in Drupal 7. Thanks.

@liquidcms I just updated about the related D8 entity translation status and we can support whoever works on a D7 port. But our team is D8 only and we will not work on a D7 port on our own.

@miro_dietiker: Are you looking for someone to comaintain the D7 version?

@DamienMcKenna i'm not even one of the maintainers. We just helped pushing the D8 port. :-)

Hi there, any news about the entity translation support?

Are there any news on this topic?

I agree with someone that commented on this topic and said that we should not rely on Replicate (Field collection module does not require Replicate).
We should avoid creating the paragraph entity whenever the translation form is prepared simply because one might not save the translated entity.

From my perspective there are 2 alternatives for working with entity translation.

1. Enable translation for paragraph field, no translation for paragraph fields.
With this approach, you end up having a distinct paragraph entity for every language.
When implementing this, all we need to do is make sure that the original paragraph entities are properly attached to the translated entity.

The current code does not save paragraphs to the translated entity because they are not properly attached to the form. There is a never-ending function that is embedding paragraphs and I suspect that's what is needed to be called in the attach process.

2. Do not translate the paragraph field, but allow translation for paragraph entities.
With this approach, you end up having the same paragraph entity for every language, but allow entity translation do its magic via field translation on paragraphs level.
It might be easier to sync data between languages but harder to make paragraphs work with the host entity language.

I could spend some time and fix this.
I just need to know what is the official Paragraphs team feedback on this.

@mihai_brb i am going to be looking at this as well (today); but if you come up with solution before i do; please post. :)

as for the approach taken, i honestly don't see the use case for option #1, so i think #2 is the only valid approach here. think of it like this:

Yes, a Paragraph is both an Entity and a Field, but in this case the concept that it is an Entity should take precedence and NOT be allowed to be translated, just the way the paragraph's parent entity (node, user, etc) isn't available for translation. Then, as you stated, let ET (so stupidly named as it is NOT translating entities) should do its thing and simply translate the underlying paragraph fields (if they have been individually designated as being translatable).

That being said, the first (simple) part of this is to replace the standard ET field setting that shows at the bottom of the field settings form to enable/disable ET for this field and simply replace it with a note stating "paragraph fields can not be translated; set their underlying fields as translatable or not".

The second (harder part) is making sure that the underlying fields get assigned the language of the paragraphs parent. Note this last sentence is somewhat misleading as technically, for ET, the parent entity does not have a language (it is UND); but its edit form selects the language being used (i.e. the language that should be assigned to all the entity's fields (and its paragraphs' embedded fields) which have been set as translatable.

Hi,

I get some strange behaviour with this patch.

First, when i added the patch everything went as expected and as described.
I added a translation for the node. The translation was not saved yet, which is fine. The I edited the translation, translated all my entities and... Voila! Exactly what I want.
The next day i try to do the exact same thing.... I add translation for the node, I save it. But then when I edit the translated nodes the Paragraph fields are not showing! It says that no paragraphs have been added yet.

I tried to find out what the reason for this was, disabled and enabled some modules, tried other approaches like #30 from here, went back to this patch again and suddenly it worked again. And then the next day... the exact same thing... the paragraph fields are not showing.

How can this be??

I hope I can help making Paragraphs translatable, my time is just very limited.

This is my first crack at patch for supporting ET; but sadly i was working against -rc3 rather than against -dev. Patch is pretty small though so perhaps someone can apply changes to -dev and re-post... and of course test.

i took the approach i mention in #16 by disabling ability to set translation for the paragraph field itself and instead i replaced the std field setting for this with a note: http://screencast.com/t/zgQkurQzqS

also, i was not able to track down where to remove the (all languages) text that gets added to fields which are shared: http://screencast.com/t/Vxg6KqVb2KS if someone can figure that out i would greatly appreciate it.

also, i have done minimal testing, and no testing with revisions. might still be some work in that area.

issues i have seen so far with my patch:

1. when editing translation, the (all languages) suffix is added regardless of how the field is set (technically i think this is bug in ET; but unlikely it will get fixed there)

2. when editing translation, the translatable paragraph fields are not pre-filled with the text from the base language - not sure how big a deal this is as it is a bit of a nuisance that it is pre-filled anyway; although to be consistent, it likely should be (likely not too difficult to fix but will leave it until other testing proves if my patch is worth continuing on)

3. for this to work, the ET setting for "enable language fallback" needs to be set (of the 3 issues; this seems to be only possible show stopper to me)

@liquidcms yes, issue 3 is an important one. And related to it, the paragraphs fields won't show if "Hide shared elements on translation forms" is checked, under the node type settings.

@liquidcms not sure how translation delete on parent entity will work for referenced paragraph entity translations.

@mihai_brb, hmm.. interesting.. so when a translation is deleted for a parent.. i guess this (should) delete the field records which are of the language of that translation. so for paragraphs, this would NOT delete the paragraph since it is UND; but should delete the paragraph's fields which are (now, with this patch) in that language.

yes, this will need to also be added and yes, i haven't looked at that case yet.

Btw, if we turn on field translation for field on Paragraph bundle, the data added to this field by node form will not be saved. So shoudln't this issue be marked as bug?

Just tested patch #18 with Entity translation.
Paragraph field no longer has the option to be translated, that should be fine.
On my Paragraph entity bundle I have 2 fields, one translated, the other is not.

When I am on translate form for a node I do not get the original paragraph filled in.
I can create new paragraphs but this way I end up having a paragraph entity for every language.

From what I understand the goal would be to have the paragraph field referencing the same paragraph entity, and only translate the referenced paragraph entity fields (when needed). For example, a referenced paragraph entity could have translated and untranslated fields. A use case for this would be when someone has referenced paragraph with images and text. Images are the same for all languages, and you only want to translate the text.

this patch is now against latest -dev and also addresses issues in #21 and #22

#21 - if ET is set to hide shared fields para fields were not showing up on translation form as the para field itself is not translatable. with this patch if any translatable field within the para in the source lang is filled in; then the entire para field form is visible when translating. ideally this would only show those fields within the para field which are not shared; but i havent added that yet.

NOTE: i had to change system weight of para module to 20 to be > weight of ET module as i didnt see a way for it to not override any changes i made before hand. if someone wants to review my code and come up with a cleaner way to do this so weight doesnt need to be changed.. :)

#22 - using hook_entity_translation_delete() i go through the parent entity and find any para fields with translatable fields and then go through and delete those field records.

from #25:

When I am on translate form for a node I do not get the original paragraph filled in.
I can create new paragraphs but this way I end up having a paragraph entity for every language.

hmm, nope, i dont think that happens. if you have a para field with a translatable and untranslatable field and you fill both of these in for the source language. then you go to translate, yes, you do not get original value filled in but the you do get the para field there (and the untranslatable field is filled in with text from source language). if you now enter translated text for the translatable field and save the translation; pretty sure you dont get a new para record.. only get the para's translatable field record added in the new language.

as for not filling in original source text; yes, i have not gotten to that yet as it seems like a bug in ET anyway as it means the user needs to now go and delete the garbage text from those fields before entering correct text. i get why they do this; and likely not too hard to fix here.. but wasn't high on priority list.

and the patch

Added hook_install for the paragraphs_update_7102() so new installations get the correct weight.

Fixed some non existence properties errors when creating new content.

Notice: Undefined variable: entity in paragraphs_form_alter() (line 486 of /Users/fred/Sites/drupal7/drupal/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_form_alter() (line 486 of/Users/fred/Sites/drupal7/drupal/sites/all/modules/contrib/paragraphs/paragraphs.module).

Fixed when adding paragraphs field into a translatable entity the message: “This is a Paragraph field. It is not translatable as a complete entity. Please set the translation mode for the paragraph's individual fields.” and removed the Field translation checkbox.
I still don’t get it the use of $form['#after_build'][] for that. @liquidcms, tell me why you did this? I commented this section of the code just in case.

Fixed to show (all languages) on child fields with no translation enabled. For some reason it doesn’t work with multiple images, hell it doesn’t work on parent either (maybe entity translation issue?)

What doesn’t work so far:
- Copy all data fields from origin language when creating a new translation.
- On translatable image fields with “Field synchronization” enabled, when adding or updating images should sync among translated languages.

@7thkey, hey, thanks for jumping in on this:

1. hook_install for weight: yup, good catch

2. notices cleanup: great, i always miss some of those

3. after_build rather than form alter: when i looked at it it wasn't available in form alter; my guess is because we have now changed the weight of the module that we get to see this after ET has modified.

4. show (all languages): sweet, that one was killing me.

todo:

5. Copy all data fields from origin language when creating a new translation.
6. On translatable image fields with “Field synchronization” enabled, when adding or updating images should sync among translated languages.

yes, i agree, 5 would be nice to be consistent; although not sure i really get the point of ET doing this anyway.

6, i don't understand. isn't field sync for i18n?

Hello, trying to make it to work with a nested bundle I notice something wrong in #29 patch...

$form[$parent_field['field_name']][LANGUAGE_NONE][0][$fieldinfo['field_name']];

should use $delta

$form[$parent_field['field_name']][LANGUAGE_NONE][$delta][$fieldinfo['field_name']];

with the index 0 always use the first paragraph field and not the current one.

This fix the duplicated Shared Labels on each field too.

Another thing...

I don't know the utility of this function, I got many errors: "paragraphs_entity_translation_delete", I comment it and errors gone. the fields are deleted properly without this equally.

Notice: Trying to get property of non-object in paragraphs_entity_translation_delete() (line 910 of /XXX/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Undefined index: field_name in paragraphs_entity_translation_delete() (line 913 of /XXX/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_entity_translation_delete() (line 914 of /XXX/sites/all/modules/contrib/paragraphs/paragraphs.module).
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mgy_dev.field_data_' doesn't exist: DELETE FROM {field_data_} WHERE (entity_id IS NULL ) AND (language = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => en ) in paragraphs_entity_translation_delete() (line 916 of /XXX/sites/all/modules/contrib/paragraphs/paragraphs.module).

those are just notices; not real errors.. just means some variable not initialized. pretty sure if that function is not there the translation records will not be deleted; just the paragraph itself is deleted so you wont see it.. but you have left clutter in your db. check the db.

patch #29 is not working for paragraph bundles which has field_collection items. Fields within the field collection is always getting saved in the same language

re #35 - doesn't surprise me.. unlikely something i would look at but feel free to suggest a patch.

I made some changes to the patch in #29 to get rid of some of the errors and notices when editing and deleting Paragraph pages. Not sure if this is the correct way to go about it, but it seems to be working for me.

Here's a new attempt at making paragraphs compatible with Entity Translation. This implementation makes use of Entity Translation's handler class system to provide an actual ET handler for translating paragraph items.

Prerequisites

• Paragraphs 7.x-1.0-rc4
• Entity Translation 7.x-1.0-beta4+10-dev
• Select "Paragraphs item" as translatable entity at admin/config/regional/entity_translation
• Enable translation for one or more fields of a paragraphs bundle

Working

• Translating a paragraph item into different languages.
• Translating nested paragraph items.
• Fields in the new translation get populated with values from source language.

Todos

• Fix: the entity holding the paragraph items must be created first without any items in order to make translation work.
• See patch: a clean fix for the bug occurring when confirming removal of a paragraph item.
• Making paragraph items translatable that were created after the initial entity translation has been added.

#38 seems to be the ideal way forward. Faced few issues, updating a latest patch

• Updated getFormLanguage to get language from the GLOBALS. This way when a creating node for first time, the languauge is set to correctly. Since its the same used when loading the form widgets, used the same here as well. Please feel to correct if there is a better approach
• Even though fields inside a bundle is selected as translatable, the field lables were displayed with the 'all languages' hint incorrectly. Added a fix to remove this if entity_translation is enabled for paragraphs
• Updated README.txt to include the steps

did the testing using Entity Translation 7.x-1.0-beta4 (please let us know if this needs to be the latest dev version)

Hello, i've installed the dev version (and applied the patch #38), with entity_translation at the latest dev and i18n at stable version. I've create a 2 new paragraphs bundles but when I click on the Add button it return this:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: n/a
ResponseText: 
ReadyState: undefined

Some has the same problem?

I've applied patch #38 to Paragraphs 7.x-1.0-rc4 and when I click on Add button it return ajax error:
Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in .../modules/contrib/entity_translation/includes/translation.handler_factory.inc on line 93
ReadyState: undefined

@aruuska, had the same issue, please check where the 'translation.handler.paragraphs_item.inc' file was created by applying the patch, it should be in [paragraph's root dir]/includes/translation.handler.paragraphs_item.inc , patch may fail and add it somewhere else like it happened to me. Also the rest of the classes are actually in entity_translation's include dir so class declaration file location is not so obvious.

It is my understanding that all patches apart from the original patch is using method B from the issue summary? Surely method A gives the most flexibility so that content editors can have different paragraphs items per translation, rather than having a set number of items from the source language.

@stella Did you make any further progress on this after your first patch? I'm trying to use this patch but I'm trying to prevent the entities from being saved on page load.

Overall #38 is working pretty nice for me.

1. +++ b/paragraphs.field_widget.inc
   @@ -453,6 +453,17 @@ function paragraphs_field_widget_form_build(&$form, &$form_state, $field, $insta
   +        // Flag the field to be processed in paragraphs_form_alter to.
   +        // avoid adding incorrect translation hints.
   +        $address = array_slice($element['#parents'], 0, -2);
   +        if (empty($form['#paragraphs_translation_fields']) || !in_array($address, $form['#paragraphs_translation_fields'])) {
   +          $form['#paragraphs_translation_fields'][] = $address;
   +        }
   
   +++ b/paragraphs.module
   @@ -1366,3 +1371,24 @@ function paragraphs_bundle_copy_info() {
   +/**
   + * Implements hook_form_alter().
   + *
   + * Checks for a value set by the embedded widget so fields are not displayed
   + * with the 'all languages' hint incorrectly.
   + */
   +function paragraphs_form_alter(&$form, &$form_state) {
   +  if (!empty($form['#paragraphs_translation_fields'])) {
   +    foreach ($form['#paragraphs_translation_fields'] as $address) {
   +      drupal_array_set_nested_value($form, array_merge($address, array('#multilingual')), TRUE);
   +    }
   +  }
   +}
   

   This assumes that all fields under the paragraph will also be translatable which is not necessarily the case.

2. Updated getFormLanguage to get language from the GLOBALS. This way when a creating node for first time, the languauge is set to correctly. Since its the same used when loading the form widgets, used the same here as well. Please feel to correct if there is a better approach

   This works for my use-case but the parent entity's language is not always the interface language, we might need find a better way to fix that.

3. +++ b/paragraphs.field_widget.inc
   @@ -700,6 +705,16 @@ function paragraphs_field_widget_embed_validate($element, &$form_state, $complet
   +    // TODO fix this
   +    // Issue: with entity translation enabled, the paragraphs_deleteconfirm_js()
   +    // callback fails with an exception due to the missing paragraphs entity property
   +    // in the forms array. In the preceeding paragraphs_remove_js() callback
   +    // however, the property is present.
   

   Is this still an issue? I couldn't reproduce it.

@geertvd, re: #44

1. This does not change the field settings, it only changes the field label (removing the "all languages" word). The issue is this label gets displayed to all fields even if the field is selected as translatable, so the better trade-off would be to remove the label to avoid confusion. btw: its the same approach done with field_collection as well
2. works fine for me as well - since using GLOBALS; one caveat is that the language used to create the Paragraph node first time should match the site language. i.e if your site language is EN, the form language drop down should have EN also. Afterwards translating to other languages work good.
3. not able to reproduce this issue

this update to the patch fixes issue where we might not want to pull language from $GLOBALS['language']->language.

there's a typo in this patch. How do I remove it?

Adding a new patch. The initial paragraphs_item created doesn't update the fields when the hostEntity is updated. So you end up with a node in english, but a paragraph item with fields in LANGUAGE_NONE.

Adding a patch for that.

This needs tests.

What's the expected behaviour after applying #38?

This is what I'm seeing:

1. Add new node. Save.
2. Add paragraphs item to node. Save.
3. Add translation. Translation loads paragraphs item with fields populated with source language.
4. Edit fields on the paragraph with translated values and save.
5. The translation displays the values from the source language, not the ones entered in the step above.
6. Edit the translation, the paragraphs item is no longer visible on the translation. It does still exists on the source language node.

Re-rolled #48 against 7.x-1.0-rc4.

Also removed the requirement for the parent entity to be untranslated, as we have a requirement to have the language specified.

Updated patch #52.

Added check for i18n_language_content so nested paragraphs work on node add.

Added is_object in paragraphs_entity_presave() on $et_handler->hostEntityHandler because handler sometimes returned empty with nested paragraphs.

Hi all
Its a temporary solution for correct work with module Entity translation.

For correct work with ET module you should be apply next patches:

1. Patch #9 for module Entity translation Link: https://www.drupal.org/node/2339315#comment-10884422
2. Patch #53 for module Paragraphs Link: https://www.drupal.org/node/2452675#comment-10985453

After apply next diff for patch entity_translation-prepopulate-form-state-2339315-8.patch

Index: modules/contrib/entity_translation/entity_translation.module
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- modules/contrib/entity_translation/entity_translation.module	(revision )
+++ modules/contrib/entity_translation/entity_translation.module	(date 1459252422000)
@@ -1343,12 +1343,15 @@
       $langcode = $element['#language'];
       $parents = $element[$langcode]['#field_parents'];
       $source_state = field_form_get_state($source_parents, $field_name, $source, $source_form_state);
-      /* This part is specific to field collections really. */
+      /* This part is specific to field collections and paragraphs really. */
       if (isset($source_state['entity'])) {
         foreach ($source_state['entity'] as $delta => $source_state_entity) {
           if ($source_state_entity instanceof FieldCollectionItemEntity) {
             $source_state['entity'][$delta] = entity_translation_clone_entity('field_collection_item', $source_state_entity);
           }
+          if ($source_state_entity instanceof ParagraphsItemEntity) {
+            $source_state['entity'][$delta] = entity_translation_clone_entity('paragraphs_item', $source_state_entity);
+          }
         }
       }
       /* End part. */

Best regards,

Small update to patch #53 on the view method.

-     $langcode = $GLOBALS['language']->language;
+     $langcode = $GLOBALS['content_language']->language;

This is to ensure we see the content language.

However, the full conditions are:

    if ($langcode == NULL) {
      $langcode = LANGUAGE_NONE;
    }

if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $this->bundle)) {
+      // Force the language code to be the current language in order to display
+      // the correct language version
+      $langcode = $GLOBALS['content_language']->language;
+    }

In my tests, just removing the $langcode override based on entity_translation condition allows the field's language from $item to be used, which is what we expect.

I welcome feedback on this particular point.

NOTES:
- We have 3 levels of nested paragraphs_items.
- We're running the entity_translation patch from @ksemihin's comment above (#59)
Patch #9 for module Entity translation Link: https://www.drupal.org/node/2339315#comment-10884422

Sorry, got content_language backwards. Should be language_content.

Me and @wroxbox at Affecto had to fix this somehow on our client project. So here's our solution as a separate module. We hope it can help in the solution.

If you have already paragraphs_item entries in the entity_translation table it's good to remove them first.
db_query("DELETE FROM entity_translation WHERE entity_type = 'paragraphs_item'");

http://dropbucket.org/node/7669

You should use these versions of entity_translation and paragraphs modules:

projects[entity_translation][type] = module
projects[entity_translation][download][type] = git
projects[entity_translation][download][url] = git://git.drupal.org/project/entity_translation.git
projects[entity_translation][download][branch] = 7.x-1.x
projects[entity_translation][download][revision] = "fe91ede055691a082e0dbd8b2fcf4795c810f24a"

projects[paragraphs][version] = "1.0-rc4"

You should apply these patches before this works.

projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/undefined_property_menu-2511966.patch"
projects[entity_translation][patch][] = "https://bitbucket.org/!api/2.0/snippets/tierakehitys/g9kXM/c8945329eee9992c7d5d0bbabe115cc44c2dbc7e/files/et-i18n_taxonomy-1661348-24.patch"
projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/entity_translation-prepopulate-form-state-2339315-8.patch"
projects[paragraphs][patch][] = "https://bitbucket.org/!api/2.0/snippets/tierakehitys/B8epy/5d975866c6bd6bd6dd5d14652e8c4ffbdc8f4d78/files/paragraphs_entity_translation_support_2452675.patch"

Our situation:
1. We have nodes translated with entity_translation.
2. Paragraphs field is not translatable (it's forbidden by the Paragraphs module).
3. Paragraph items are translatable by entity_translation module.
4. Paragraph item fields are translatable.

The module allows us to translate nodes with separate paragraphs items. In other words it's possible to have different number of paragraph items on every translation.

@jiv_e
I have a question about your helper module paragraphs_translation (to make entity translation work better). Did you use it with the paragraphs-7.x-1.x-dev with any patches applied? Any other modules needed? I tried it and the extra paragraphs of the translated para fields are still visible in the source language.

Only paragraph fields in the para field are set as translatable. Not the para field itself.

Hi!

I'm sorry! I asked @wroxbox to add details on the applied patches, but he's obviously too busy. :)

Here!

projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/undefined_property_menu-2511966.patch"
projects[entity_translation][patch][] = "https://bitbucket.org/!api/2.0/snippets/tierakehitys/g9kXM/c8945329eee9992c7d5d0bbabe115cc44c2dbc7e/files/et-i18n_taxonomy-1661348-24.patch"
projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/entity_translation-prepopulate-form-state-2339315-8.patch"

I edited the original comment also.

@jiv_e
Not working for me at the moment. Deleted the translated ET para bundles first.
Applied the ET module patches. (applied patches on the ET 7.x-1.0-beta version of the module)
What patches were applied on the paragraphs module itself in your use case? (applied on which version of the module?)

Sorry, I forgot to check paragraphs patches!

projects[paragraphs][version] = "1.0-rc4"
projects[paragraphs][patch][] = "https://bitbucket.org/!api/2.0/snippets/tierakehitys/B8epy/5d975866c6bd6..."

I don't really now about these patches. I just did the module. Maybe @wroxbox can tell more about these. I just picked these up from the makefile.

Thank you for your help.
Can I bother you with one last thing? In your makefile what version of entity translation is specified? I could patch the dev version of ET.
In the end it does not work for me. The extra paragraphs appear in the source language still.

drush sql-query "DELETE FROM entity_translation WHERE entity_type = 'paragraphs_item'"

entity_translation-7.x-1.x-dev with patches
entity_translation-prepopulate-form-state-2339315-8.patch
et-i18n_taxonomy-1661348-24.patch
undefined_property_menu-2511966.patch

paragraphs-7.x-1.0-rc4 with patches:
paragraphs_entity_translation_support_2452675.patch

paragraphs_translation

No need for the paragraphs translation module.
In the end I was able to fix the extra paragraphs of the translated node in the source language by (or vice versa):
* disabling language fall back (stops cloning the paragraph item to the other languages when not needed)
* disable translation on the paragraph bundle and set the fields of paragraph field as translatable.
When the node exists in only one language, the language switcher language link is disabled then (via a custom override of the language locale menu block). Instead of showing a message the translation is not available.
patch  paragraphs-entity_translation_support-2452675-53.patch 

tried #61 patch with instructions from #60
but when saving translated content I get this fatal error

Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/includes/translation.handler_factory.inc on line 93 Call Stack: 0.0001 237860 1. {main}() /home/drupalpro/websites/domain.dev/index.php:0 0.0492 2949052 2. menu_execute_active_handler() /home/drupalpro/websites/domain.dev/index.php:21 0.0493 2949672 3. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/menu.inc:527}() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0493 2950148 4. entity_translation_add_page() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0494 2951272 5. _entity_translation_callback() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:690 0.0494 2951364 6. call_user_func_array:{/home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:701}() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:701 0.0494 2951584 7. node_page_edit() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:701 0.0495 2951940 8. drupal_get_form() /home/drupalpro/websites/domain.dev/modules/node/node.pages.inc:14 0.0495 2952496 9. drupal_build_form() /home/drupalpro/websites/domain.dev/includes/form.inc:130 0.0544 4141996 10. drupal_process_form() /home/drupalpro/websites/domain.dev/includes/form.inc:385 0.3484 8590328 11. form_execute_handlers() /home/drupalpro/websites/domain.dev/includes/form.inc:903 0.3484 8594516 12. i18n_node_form_submit() /home/drupalpro/websites/domain.dev/includes/form.inc:1519 0.3555 8583756 13. node_save() /home/drupalpro/websites/domain.dev/sites/all/modules/i18n/i18n_node/i18n_node.module:467 0.3591 8600068 14. field_attach_presave() /home/drupalpro/websites/domain.dev/modules/node/node.module:1086 0.3591 8600096 15. _field_invoke() /home/drupalpro/websites/domain.dev/modules/field/field.attach.inc:914 0.3593 8602336 16. paragraphs_field_presave() /home/drupalpro/websites/domain.dev/modules/field/field.attach.inc:209 0.3593 8603004 17. ParagraphsItemEntity->save() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/paragraphs.module:742 0.3594 8603308 18. EntityAPIController->save() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/ParagraphsItemEntity.inc:406 0.3604 8603916 19. EntityAPIController->invoke() /home/drupalpro/websites/domain.dev/sites/all/modules/entity/includes/entity.controller.inc:443 0.3614 8604608 20. module_invoke_all() /home/drupalpro/websites/domain.dev/sites/all/modules/entity/includes/entity.controller.inc:355 0.3618 8606404 21. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/module.inc:951}() /home/drupalpro/websites/domain.dev/includes/module.inc:951 0.3618 8606704 22. paragraphs_entity_presave() /home/drupalpro/websites/domain.dev/includes/module.inc:951 0.3618 8606704 23. entity_translation_get_handler() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/paragraphs.module:1382 0.3618 8606704 24. EntityTranslationHandlerFactory->getHandler() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:1892

when trying to set a particular paragraphs field to "enable or disable translation" I get this

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /en/batch?id=327&op=do StatusText: OK ResponseText: Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/includes/translation.handler_factory.inc on line 93 Call Stack: 0.0000 129384 1. {main}() /home/drupalpro/websites/domain.dev/index.php:0 0.0272 2506600 2. menu_execute_active_handler() /home/drupalpro/websites/domain.dev/index.php:21 0.0273 2507536 3. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/menu.inc:527}() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0273 2507656 4. system_batch_page() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0273 2507708 5. _batch_page() /home/drupalpro/websites/domain.dev/modules/system/system.admin.inc:2384 0.0274 2508160 6. _batch_do() /home/drupalpro/websites/domain.dev/includes/batch.inc:80 0.0274 2508280 7. _batch_process() /home/drupalpro/websites/domain.dev/includes/batch.inc:161 0.0288 2527316 8. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/batch.inc:284}() /home/drupalpro/websites/domain.dev/includes/batch.inc:284 0.0288 2527508 9. entity_translation_translatable_batch() /home/drupalpro/websites/domain.dev/includes/batch.inc:284 0.0424 2937892 10. entity_translation_get_handler() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.admin.inc:580 0.0424 2940896 11. EntityTranslationHandlerFactory->getHandler() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:1892

I had paragraph field not translatable when I try to enable translation for it I get

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /en/batch?id=328&op=do StatusText: OK ResponseText: Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/includes/translation.handler_factory.inc on line 93 Call Stack: 0.0000 129384 1. {main}() /home/drupalpro/websites/domain.dev/index.php:0 0.0261 2506748 2. menu_execute_active_handler() /home/drupalpro/websites/domain.dev/index.php:21 0.0262 2507684 3. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/menu.inc:527}() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0262 2507804 4. system_batch_page() /home/drupalpro/websites/domain.dev/includes/menu.inc:527 0.0262 2507856 5. _batch_page() /home/drupalpro/websites/domain.dev/modules/system/system.admin.inc:2384 0.0262 2508308 6. _batch_do() /home/drupalpro/websites/domain.dev/includes/batch.inc:80 0.0262 2508428 7. _batch_process() /home/drupalpro/websites/domain.dev/includes/batch.inc:161 0.1278 4081816 8. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/batch.inc:284}() /home/drupalpro/websites/domain.dev/includes/batch.inc:284 0.1278 4082008 9. entity_translation_translatable_batch() /home/drupalpro/websites/domain.dev/includes/batch.inc:284 0.1781 4460192 10. _entity_translation_update_field() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.admin.inc:610 0.1782 4461272 11. field_attach_presave() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.admin.inc:657 0.1782 4461340 12. _field_invoke() /home/drupalpro/websites/domain.dev/modules/field/field.attach.inc:914 0.1783 4463668 13. paragraphs_field_presave() /home/drupalpro/websites/domain.dev/modules/field/field.attach.inc:209 0.1919 4612460 14. ParagraphsItemEntity->save() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/paragraphs.module:742 0.1919 4612764 15. EntityAPIController->save() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/ParagraphsItemEntity.inc:406 0.1980 4619432 16. EntityAPIController->invoke() /home/drupalpro/websites/domain.dev/sites/all/modules/entity/includes/entity.controller.inc:443 0.1991 4620124 17. module_invoke_all() /home/drupalpro/websites/domain.dev/sites/all/modules/entity/includes/entity.controller.inc:355 0.1996 4621916 18. call_user_func_array:{/home/drupalpro/websites/domain.dev/includes/module.inc:951}() /home/drupalpro/websites/domain.dev/includes/module.inc:951 0.1996 4622216 19. paragraphs_entity_presave() /home/drupalpro/websites/domain.dev/includes/module.inc:951 0.1996 4622216 20. entity_translation_get_handler() /home/drupalpro/websites/domain.dev/sites/all/modules/paragraphs/paragraphs.module:1382 0.1996 4622216 21. EntityTranslationHandlerFactory->getHandler() /home/drupalpro/websites/domain.dev/sites/all/modules/entity_translation/entity_translation.module:1892

@johanvdr Sorry for the inconvenience! I edited the original comment and added the details there. See: https://www.drupal.org/node/2452675#comment-11082609

Followed instructions from #62

following patch has a warning
https://bitbucket.org/!api/2.0/snippets/tierakehitys/g9kXM/c8945329eee99...

Checking patch entity_translation.admin.inc...
Checking patch entity_translation.module...
Checking patch entity_translation.node.inc...
Checking patch entity_translation.taxonomy.inc...
b.patch:232: new blank line at EOF.
+
Checking patch includes/translation.handler.taxonomy_term.inc...
Applied patch entity_translation.admin.inc cleanly.
Applied patch entity_translation.module cleanly.
Applied patch entity_translation.node.inc cleanly.
Applied patch entity_translation.taxonomy.inc cleanly.
Applied patch includes/translation.handler.taxonomy_term.inc cleanly.
warning: 1 line adds whitespace errors.

Notes #62 3. is a little confusing
I think you mean the settings here admin/config/regional/entity_translation > TRANSLATABLE ENTITY TYPES

On installing the module does not show up in the modules list
paragraphs_translations.module should be named paragraphs_translation.module and then it can be enabled

After that It seems to work as advertised with some small problems

a) there is not language local tabs when you edit one language to go directly to the other language
instead you have to go to
b) the Language switcher (Content) BLOCK is not working (translation is disabled when you are on original language)
Language switcher (User interface text) BLOCK works fine though

But there is a major problem as well last note from #62 is not correct
"The module allows us to translate nodes with separate paragraphs items. In other words it's possible to have different number of paragraph items on every translation."
I Created new paragraph item) only on the translated language (secondary language) and it actually appears on the original language ?!!
On the original language edit forms an empty paragraph item appears that if its DELETED it deletes the ORIGINAL paragraph item (meaning from the translated language)

I got translating Paragraphs working (not with the entity translation module but with the same goal):
I noticed the additional module: paragraphs i18n. (so you are using the latest paragraph version which you can update without keeping the patches in account)
Download the dependencies.

Then you'll notice it saves the paragraph in an entity (paragraph bundle) for that language.
Now I had issues rendering the paragraph field in my node.

So I made a .tpl specially for that content type that has that paragraph field. And copied over my node.tpl code from my basetheme to that file.
Then I added this code to render the paragraph field.

// Paragraphs render fix
    foreach ($content['field_page_layout']['#object']->field_page_layout[$GLOBALS['language']->language] as $paragraph){
        $paragraphEntity = entity_load("paragraphs_item",array($paragraph['value']));
        //Per Paragraph field on the page-node get a renderable array of fields!
        $renderableParagraphBundle = field_attach_view("paragraphs_item", $paragraphEntity[$paragraph['value']], "full", $langcode = $GLOBALS['language']->language, $options = array());
        print render($renderableParagraphBundle);
    }

Hope I helped,
- thomas_vc

@GiorgosK

I got the same problem when deleting the translated paragraph, after applying @jiv_e 's patch in #62

@GiorgosK

For the problem when deleting the translated paragraph, I found the reason and somehow "fixed" it.
Take a look at the file "paragraphs/ParagraphsItemEntity.inc", and the problem it's in the "deleteRevision()" function.
In fact, I don't know exactly how to make the code inside works with entity translation, so I disabled all this part:

/*
    else {
      $row = db_select('paragraphs_item_revision', 'r')
        ->fields('r')
        ->condition('item_id', $this->item_id)
        ->condition('revision_id', $this->revision_id, '<>')
        ->execute()
        ->fetchAssoc();
      // If no other revision is left, delete. Else archive the item.
      if (!$row) {
        $this->delete();
      }
      else {
        // Make the other revision the default revision and archive the item.
        db_update('paragraphs_item')
          ->fields(array('archived' => 1, 'revision_id' => $row['revision_id']))
          ->condition('item_id', $this->item_id)
          ->execute();
        entity_get_controller('paragraphs_item')->resetCache(array($this->item_id));
        entity_revision_delete('paragraphs_item', $this->revision_id);
      }
    }
    */

At least, it works for me. Hope it helps for you too.

Problem with paragraphs inside taxonomy term.

breaks at entity_save($term).

Still needs work...

I rerolled the patch against current 7.x-1.x-dev and added an implementation of hook_entity_translation_source_field_state_alter() (added to entity_translation 7.x-1.0-beta5).

Add a version of the patch from #76 but rerolled against current release 7.x-1.0-rc4.

PATCH HAS WRONG PATCH LEVEL.

And the version of the 7.x-1.0-rc4 reroll with the correct patch level.

PATCH HAS WRONG PATCH LEVEL.

This time it should be with the right patch level. Sorry for the noise.

Patch #79 is not working for me and return an error message if i try to add a paragraph item

PHP Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in .../sites/all/modules/contrib/entity_translation/includes/translation.handler_factory.inc on line 93...

Instalation:
entity_translation 7.x-1.0-beta5
paragraphs 7.x-1.0-rc4 + #79 patch
paragraph bundles are enabled in entity translation configuration
paragraph field in node is not translatable
fields inside paragaph items are translatable

any ideas?

after patch there is no folder /includes with file translation.handler.paragraphs_item.inc

OK, I seriously managed to goof up my patches yesterday. I went home and got a decent nights sleep and took extra care rerolling them today.

So attached now is a rerolled patch against current 7.x-1.x-dev with an an implementation of hook_entity_translation_source_field_state_alter() (added to entity_translation 7.x-1.0-beta5).

There is also a patch against current stable release 7.x-1.0-rc4.

The patches should have the right patch level and shouldn't leave out half the code this time. Really sorry for the noise.

Thank you very much! 7.x-1.x-dev + patch#80 is working very well :)

Changing status to "needs review" so the testbot does its thing.

I still think there ought to be tests for this.

Hi there,

A quick test (haven't looked to deep into it tho) seemed pretty ok when the paragraph item is attached to a node. However, when attaching it to a taxonomy term I get the same error as parrot (#74). Briefly looking at the code revealed that the newly added class EntityTranslationParagraphsItemHandler (file translation.handler.paragraphs_item.inc) uses 'node' hard coded.

  public function __construct($entity_type, $entity_info, $entity) {
    if (method_exists($entity, 'hostEntity')) {
      $this->hostEntity = $entity->hostEntity();
      $host_entity_type = (isset($this->hostEntity->type)) ? 'node' : 'paragraphs_item';
      if ($host_entity_type == 'paragraphs_item') {// A nested paragraphs field
        // Look for the parent host entity
        while (method_exists($this->hostEntity, 'hostEntity')) {
          $this->hostEntity = $this->hostEntity->hostEntity();
        }
      }

      $this->hostEntityHandler = entity_translation_get_handler('node', $this->hostEntity);
    }
    parent::__construct('paragraphs_item', $entity_info, $entity);
  }

What if you'd replace 'node' with $entity->hostEntityType()? Would that work?

To tie in with my comment above, here's an idea how to use $entity->hostEntityType() instead of hard coded 'node':

  public function __construct($entity_type, $entity_info, $entity) {
    if (method_exists($entity, 'hostEntity') && $this->hostEntity = $entity->hostEntity()) {
      $host_entity_type = !empty($entity->hostEntityType()) ? $entity->hostEntityType() : 'paragraphs_item';
      if ($host_entity_type == 'paragraphs_item') {// A nested paragraphs field
        // Look for the parent host entity
        while (method_exists($this->hostEntity, 'hostEntity')) {
          $this->hostEntity = $this->hostEntity->hostEntity();
        }
      }

      $this->hostEntityHandler = entity_translation_get_handler($entity->hostEntityType(), $this->hostEntity);
    }
    parent::__construct('paragraphs_item', $entity_info, $entity);
  }

Also note that the host entity needs to be available to proceed.

Thanks! #80 for 7.x-1.0-rc4 work fine here, after the content is created with several paragraphs all work fine, the versions in another languages area created too, but I have some shared fields, for example images and numbers. If later I change one this, the field go out of sync in the other languages, I can deal with that, but this is a normal behaviour?

Sorry, I was making the paragraph field translatable and not the fields inside. Now all the shared fields are synchronized, perfect!

Hello I had some problems with nested paragraphs and the patch #80 for 7.x-1.0-rc4, then I try with the dev version and work better. Only two things:

When I add a second or more paragraphs each one copy the same text on a translatable field in the first paragraph.

After upload an image inside a paragraph got this error: Warning: Invalid argument supplied for foreach() en element_children() (line 6568 of /htdocs/test/includes/common.inc).

EDIT: Both cases occur only when create a page the first time, if you save and then edit again the problems dissapear

Here's a re-rolled patch that includes something based on the suggestion from comment 86 above.

Hi,

ET enabled on paragraphs.
"Basic page" translatable at field level.
Paragraph bundle "p_a" embed in "Basic page" as non translatable, with translatable fields.
Paragraph bundle "p_b", embed in "p_a" as non translatable, with translatable fields.

With #90, when I click to add a p_b paragraph, I encount the following ajax error:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: n/a
ResponseText: 
( ! ) Fatal error: Call to undefined method stdClass::hostEntityType() in /sites/all/modules/contrib/paragraphs/includes/translation.handler.paragraphs_item.inc on line 29

When I see the code on translation handler :

     // A nested paragraphs field.
      if ($host_entity_type == 'paragraphs_item') {
        // Look for the parent host entity.
        while (method_exists($this->hostEntity, 'hostEntity')) {
            $this->hostEntity = $this->hostEntity->hostEntity();
            $host_entity_type = $this->hostEntity->hostEntityType();
        }
      }

It iterate on entities to go to parent while the current entity has 'hostEntity' method. The problem is the process iterate while it find paragraphs, and in the last loop, it set $this->hostEntity as the parent (not a paragraph).
In my case:
p_b: check hostEntity method: yes; $this->hostEntity = p_a.
p_a: check hostEntity method: yes; $this->hostEntity = basic page

In the loop, we are on basic page and we try $this->hostEntity->hostEntityType()... But no way because node doesn't has hostEntityType() method...

With a little check it work correctly to add paragraph in paragraph:

        while (method_exists($this->hostEntity, 'hostEntity')) {
          if ($this->hostEntity->hostEntityType() == 'paragraphs_item') {
            $this->hostEntity = $this->hostEntity->hostEntity();
            $host_entity_type = $this->hostEntity->hostEntityType();
          }
          else {
            break;
          }
        }

But I think it's not the better way... But no time yet to find more stylish way to do it now...

No one has encounted this problem with the last patch ?

Sorry, I'd rerolled the patch and included suggested changes without testing those changes. Thanks for testing for us! Here's another attempt, based on what I think was really intended. Again, untested.

Argh, just spotted a PHP warning that would be thrown. So ignore my last comment! Try again...

Hi all, I had an issue by adding some paragraph of the same type to a single node, and I find someone that had the same problem here:
https://www.drupal.org/node/2786235

I found that the issue comes with this patch, and I try to fix it, I don't know if this is a good way to solve, but in my case it works! Hopes this helps someone else.

Sorry forgot to include translation.handler.paragraphs_item.inc in the patch. Here it is.

Hi all, I faced the last issue again while using nested paragraphs, I tried to fix it, hope it helps and it works!

Hi everyone. I've been following this thread with great interest. Will this be released as part of the Paragraphs module soon? I know it's hard to say sometimes, but I thought I'd ask.

Found an error using nested paragraphs in #97

Updated patch attached.

after enable translations in filed settings

#100 patch
Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in /sites/all/modules/entity_translation
/includes/translation.handler_factory.inc on line 93

Fix bug causing incorrect language in translated paragraph fields.

@proweb.ua
Try registry rebuild with drush rr.
You may need to install registry_rebuild first: drush dl registry_rebuild

@bleedev, thanks
#103 works

Trying #103 I found that if you add an additional paragraph after the node was created this doesn't appear in the translated version.

1- Create a node with some paragraphs
2- Translate the node
3- Edit the node and add a new paragraph
4- The new paragraph only appear in the edited version (view and edit mode)

Edit: Making the paragraph field not translatable (the text field in the paragraph bundle yes) and unchecking "Hide shared elements on translation forms" in the entity translation options show the new paragraph in the translated content, but empty.

I used patch #97, and it seemed to work for me with new content. However, I had initial language neutral content that was being deleted when I changed to a locale (initially, the site was set up as all Language Neutral, but now most content types and entities are being moved to specific languages. As a workaround for the older content, I commented out these delete calls in the paragraphs_field_update function in paragraphs.module:

$item->setHostEntity($entity_type, $entity, $langcode, FALSE);
$item->deleteRevision(TRUE);

This seems to keep the Paragraphs intact. I haven't tested fully, but I'm guessing that with these commented out, I wouldn't be able to actually delete Paragraphs, so my goal is to revert back once I've switched all content from language neutral to the specific language.

I've found a bug in #97, when I create parent entity in default language, and wanted to translate it it wasn't falling back to default language.
Paragraphs fields on the form were empty instead of getting copy of default language.
In order to fix the problem I've changed that code in paragraphs_field_widget_form_build():

if (module_exists('i18n')) {
  $content_language = i18n_language_content();
  $language = $content_language->language;
}

to this:

if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $paragraph_item->bundle)) {
  $language = entity_language('node', $form['#entity']);
}

To @PawelR and others - creating a patch is a great thingy but its much more easier to track changes and do reviews in patches if you guys provide interdiff as explained in https://www.drupal.org/documentation/git/interdiff.

I found that in the current supported version of the module, scenario A seems to work fine. Enable translation on the field of the host entity, but do not enable translation of the fields within the paragraph bundle. Enabling translation on both causes the paragraph field not to render any content.

I'm not sure what the ultimate plan to fix this is, but for now I just updated the README.txt file with a note. I was thinking of submitting that as a patch, but as this issue is being worked on that doesn't seem appropriate.

@PawelR: your last patch is incomplete.

@bleedev: Patch from #103 is working flawlessly with latest dev version of paragraphs. THANKS !!!

Here's an updated patch.

Sorry last patch is not good, there are missing files.

Here the good one.

Updated patch, including patch from #2562463: Parent entity access check throws PHP notice because $nid nor $vid are set.

Hi all,

Since using this patch, I had a lot of problem in my Fieldable Panels Panes.

The previous patch assume Paragraphs to be used with Nodes (see comment #110), but Paragraphs can be used with any kind of entity, like Fieldable Panels Panes.
The following patch fix this, now it's working without any single glitches.

Hi all,

The patch I submitted in #120 has a slight problem.

When I create a Fieldable Panels Pane(FPP) containing paragraphs, the variable $langcode passed to paragraphs.field_widget.inc::paragraphs_field_widget_form_build() is set to 'und'.

And thus, when saving the FPP, the paragraphs saved in the DB are saved with the 'und' language.
And all the paragraphs fields are empty => This is the real issue for the client.

To get over this, the creation of a FPP has to be done in 2 steps. First, create the FPP without the Paragraphs, then edit the FPP add the paragraphs.

If we do that, then it works fine.

I'm trying to find a solution for this issue since I posted the patch, but to be honest, I reach the end of my knowledge and patience, a little help would be greatly appreciated.

Re-rolled #103 with update from https://www.drupal.org/node/2831973

@bleedev

Your patch is not valid. This assume that a paragraph is always attached to a node. However, you can attach paragraphs to Fieldable Panels Panes or Beans.

You should use:

      // Set the form language to the current language for translation.
      if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $paragraph_item->bundle)) {
        $language = entity_language($instance['entity_type'], $form['#entity']);
      }
      else {
        $language = $GLOBALS['language']->language;
      }

Instead of

      // Set the form language to the current language for translation.
      if (module_exists('i18n')) {
        $content_language = i18n_language_content();
        $language = $content_language->language;
      }
      else {
        $language = $GLOBALS['language']->language;
      }

Here is a re-roll of @Pol's patch in #120 with the update for #2831973: Make langcode property public by @bleedev that I'm currently testing.

My latest patch in #125 does not include support for non-node host entities as mentioned by @Pol in #124.

And here is the updated patch:

• Based on patch from @Pol in #120
• Adding changes for #2831973: Make langcode property public from @bleedev in #122
• Adding change for non-node host entity suggested by @Pol in #124

In initial testing, I was able to create a content with three levels on nested paragraphs and translate them.

I got mixed up please disregard comments #126 and #127.

When using the patch in #127 with three levels of nested paragraphs (paragraphs in paragraphs in paragraphs in nodes), I encountered issue with MalformedEntityException. The issue was with the line $language = entity_language($instance['entity_type'], $form['#entity']); proposed by @Pol. On some occasion, the form['#entity'] does not match the actual host entity type. I applied the patch for #2564327: Host entity problems (ajax errors / nested paragraphs / UI speed) and changed the line to $language = entity_language($element['#host_entity_type'], $element['#host_entity']);.

The attached patch combine fixes for this issue, #2564327: Host entity problems (ajax errors / nested paragraphs / UI speed) and #2831973: Make langcode property public and allowed me to properly edit and translate paragraphs.

Patch in #130 is broken, here is the correct one.

Dear @pbuyle,

Your patch is working flawlessly.
We should maybe ease the work of the maintainer and provides single patches... but to be honest, I have the impression that the D7 version is no more maintained :(

#131 Is mostly working for me:

1. When setting 'Hide shared elements on translation forms' @admin/config/regional/entity_translation to TRUE on the parent entity, paragraphs are not shown in the edit form since the paragraph itself isn't translatable. (the fields inside are)

2. When setting 'Hide shared elements on translation forms' @admin/config/regional/entity_translation to FALSE on the parent entity, paragraphs are shown but "(all languages)" is missing from the paragraph field. This should be added because paragraphs are deleted for all translations when you remove it on any translation edit form.

Rerolled #131 based on current 7.x-1.x-dev branch.

Hi Feuerwagen,

Your patch doesn't apply.

Here's an updated patch.

Heads up; this thing just got committed to Entity Translation - it may affect this patch:
https://www.drupal.org/node/2849464

version = "7.x-1.0-rc5+11-dev"
core = "7.x"
project = "paragraphs"
datestamp = "1487357266"

I have a problem with entity translation and Paragraphs, after applying the patches

#136 2452675-7.x-1.x-reroll.patch
and #134 paragraphs-entity_translation-2452675-134.patch

above.

When I set display mode of paragraphs field to default (full) I have only untranslated fields printed, every field set as "translatable" will not be rendered whatsoever.

I found that modifying paragraphs_field_formatter_view paragraphs.field_formatter.inc, adding

global $language_content;
$langcodecontent = $language_content->language;

and modifying entity view call as

$element[$delta]['entity'] = $paragraph->view($view_mode,$langcodecontent);

(e.g. passing site langcode to the function)

renders every field, be it translatable or not.

I don't know if it is the right way to do so, and I ask for developers to inspect this problem.

#136 needs to be rewritten using new Entity Translation API.(see change record)

I will try to do it this week.

Hey there! A couple of days ago I managed to re-roll this and get Entity Translations working for Paragraph items on a project I'm working on. Here's the re-rolled patch!

I've just started testing and making edits, but so far, #140 is working for me. Thanks!

It seems that patch #140 applies to 7.x-1.0-rc5 and not 7.x-1.x-dev. Moreover, when patching upon 7.x-1.0-rc5, I get this error :

Error : Class 'EntityTranslationParagraphsItemHandler' not found dans EntityTranslationHandlerFactory->getHandler() (ligne 93 dans /www/sites/all/modules/entity_translation/includes/translation.handler_factory.inc).

I created a patch based on #140 that works on 1.x-dev.

The patch must be anyway tested in order to verify if it works for op issue.

Are you sure that your patch is complete ?

Tips: use git diff --cached to create your patch.

Sorry, I pushed only the patch for the rejected part. I try to add the complete patch as soon as I can.

Here is a reroll of #140

Better with the patch file...

Working in a site today I notice that the entity_translation table have +6k records and I have only ~300 paragraphs items in 3 languages. Now I have +6k records because I delete and import the content several times with feeds and this process never delete the previous paragraphs items. You can delete paragraphs items or nodes and the records still there forever in the entity_translation table.

#147 is working great with paragraphs (7.x-1.0-rc5) on "a clean installation". Excellent job! Thank you all.

However I’ve noticed that existing paragraph Items disappear when using combination of i18n and entity_translation. schwarli4783 opened a issue here: Paragraph Items disappear when using combination of i18n and entity_translation

+++ b/ParagraphsItemEntity.inc
@@ -514,6 +514,12 @@ class ParagraphsItemEntity extends Entity {
+    if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $this->bundle)) {

This prevents translated field values from being displayed if the paragraphs_item entity is marked as not translatable (use case B from the issue summary). The same code can be found in the translation handler added by this patch.

Edit: This works correctly after marking paragraphs items as translatable in the entity translation configuration. It stands to reason wether this should be required for paragraphs items that only act as intermediate/wrapping entity, but since field_collection currently lists the same configuration requirement in its readme there might be no way around it. /Edit

For reference, this is what field_collection does: FieldCollectionItemEntity::view()

Field Collection also checks the translation status of the parent entity (haven't checked, but I assume this will happen recursively), which seems to be a more sound approach: EntityTranslationFieldCollectionItemHandler

+++ b/includes/translation.handler.paragraphs_item.inc
@@ -0,0 +1,64 @@
+  public function getFormLanguage() {

Deprecated since entity translation 7.x-1.0-beta6.

I'd also like to emphasize what DamienMcKenna has stated twice already: We need tests, otherwise we'll continue to get manual confirmations for either case A or B without definitive proof that this patch is working for either.

+++ b/includes/translation.handler.paragraphs_item.inc
@@ -0,0 +1,64 @@
+      $this->hostEntityHandler = entity_translation_get_handler($host_entity_type, $this->hostEntity);

This line should read:

      if (!empty($this->hostEntity)) {
        $this->hostEntityHandler = entity_translation_get_handler($host_entity_type, $this->hostEntity);
      }

because entity_translation_get_handler() will return the last created translation handler for that entity type if the passed entity is null.

This is especially problematic when multiple paragraphs items are created and populated via entity_metadata_wrapper(), causing some translatable field items to be saved under the wrong language.

Hi everyone,

I was wondering if I could interject something.

The entity key for language was defined as "langcode" in paragraphs-entity_translation-2452675-122.patch. Is there a reason why the entity key was specified as "langcode"?
Most other entities use "language" as their entity key for language (nodes, taxonomy terms, comments).

Also, Lingotek's customers rely on patches in this thread for translation of paragraphs.

I propose we change the entity key from "langcode" to "language" for paragraphs items. Attached is a patch with the change.

Hi everyone.
#147 is working great with paragraphs (7.x-1.0-rc5). thanks a lot.

However there is still some bug.
I have tested it and want to clarify more details about what #156 had mention.

From language neutral to specific language it works great.

However when a user selected a specific language for the node and created paragraph, the content of will disappear when user switching to other language including switching back to language neutral. This will only happen in editing page, for preview page the content still there. When switching it back to the previous language that we set at first, the content will appear back.

Is there any solution for this? As what if a user accidentally save to the wrong language and wanted to switch it back.

Yes this is one of two problems that I have too.

1- Fields are not translated in the paragraph creation
2- Paragraphs are not deleted when the node or paragraph is deleted

I fix this two problems with a custom module

/**
 * Implements hook_entity_insert().
 */
function MODULE_entity_insert($entity, $type) {
  if ($type == 'paragraphs_item') {
    _MODULE_process($entity, $type);
  }
}

/**
 * Translate fields inside paragraphs item
 */
function _MODULE_process($entity, $type) {

  $languages = array_keys(language_list());
  $values = array();
  $default_lang = language_default();
  $source = $default_lang->language;
  $handler = entity_translation_get_handler('paragraphs_item', $entity, TRUE);

  if(($key = array_search($source, $languages)) !== false) {
    unset($languages[$key]);
  }

  foreach ($languages as $langcode) {

    $translation = array(
      'translate' => 0,
      'status'    => 1,
      'language'  => $langcode,
      'source'    => $source,
    );

    foreach (field_info_instances('paragraphs_item', $entity->bundle) as $instance) {

      $field_name = $instance['field_name'];
      $field = field_info_field($field_name);

      if ($field['translatable']) {
        $value = $entity->{$field_name}[key($entity->{$field_name})];
        $values[$field_name][$langcode] = $value;
        $entity->{$field_name}[$langcode] = $value;

        $handler->setTranslation($translation, $values);
        $handler->saveTranslations();

        field_attach_update('paragraphs_item', $entity);
      }
    }
  }
}

/**
 * Implements hook_entity_delete().
 */
function MODULE_entity_delete($entity, $type) {
  if ($type == 'paragraphs_item') {
    foreach (array('entity_translation', 'entity_translation_revision') as $table) {
      $res = db_delete($table)
        ->condition('entity_type', $type)
        ->condition('entity_id', $entity->item_id)
        ->execute();
    }
  }
}

Rerolled #156 against 7.x-1.0-rc5.

@jbhovik What patch did you base #156 on? Can you please add an interdiff?

@Stefdewa Please don't reroll against older commits. rc5 is not the most recent commit in 7.x-1.x.

@ciss, I based my patch on paragraphs-entity_translation-2452675-146.patch. I changed only one line from "'language' => 'langcode'," to "'language' => 'language',"

@Stefdewa thanks for the newest patch. One problem I have is that on translation form paragraphs field is empty. I would like to see paragraphs items in original language ready to translate. Instead I see message: No Paragraphs added yet. Select a Paragraph type and press the button below to add one. So I need to recreate paragraphs structure on every translated node.

@codium this is because at the moment of the paragraph creation the fields inside are not properly translated, see #158

I applied #156 patch, but there printed an error message

Fatal error: Class 'EntityTranslationParagraphsItemHandler' not found in .../modules/contrib/entity_translation/includes/translation.handler_factory.inc on line 93
ReadyState: undefined

I try to find why it displays the error, then I figured out the "translation.handler.paragraphs_item.inc" that put in the wrong path.
It needs to put into the includes folder. It doesn't just put in the root of paragraph folder.

I propose we change the entity key from "langcode" to "language" for paragraphs items.

@jbhovik What implications does this change have? Will it break existing sites that already have #147 applied?

+++ b/includes/translation.handler.paragraphs_item.inc
@@ -0,0 +1,64 @@
+  public function getTranslations() {
+    return $this->hostEntityHandler ? $this->hostEntityHandler->getTranslations() : parent::getTranslations();
+  }

This breaks hook_entity_translation_insert() for nodes:

1. The method may return the translations property of its host entity (if the translations are already set on the entity). This property contains an object which therefore gets passed around by reference.
2. When saving a translation, entity_translation modifies the "hook" information in the translations object. By default the hook will be set to "insert". This string determines wether hook_entity_translation_insert() or hook_entity_translation_update() will be invoked.
3. When it's time to save the node's translation, the hook information is missing and defaults to "update". This causes entity_translation to invoke the wrong hook.

@ciss,

I suppose it would depend on site specifics whether or not changing from patch #147 to #156 would break anything. I proposed the change because the Lingotek module contains some code that uses the entity key for language for every entity type, and "language" is common for most other entity types.

If certain modules or certain code requires "langcode" as the entity key for language, a change from #147 to #156 could break some things, but "language" should be a better choice for the language entity key.

I proposed the change because the Lingotek module contains some code that uses the entity key for language for every entity type, and "language" is common for most other entity types.

If they rely on a convention then they're doing it wrong. The patch already specified its language key in hook_entity_info(), and Lingotek should use that info. Imo this change serves no real purpose, and until someone has added tests for this issue we should probably stay away from introducing unnecessary changes to existing patches.

@ciss That's really well put, I'd totally agree. I was a bit worried seeing this back & forth about the extra unnecessary change.

Update to #156 which adds a property_exists check for 'hostEntityHandler' in the paragraphs_entity_presave hook.

Was running into an issue where entity translation on a site for another entity was affecting updating existing paragraph items. This patch provided the fix, however it caused an issue after saving because it expects the handler to exist even though entity translation is not enabled for paragraph items.

My proposal of entity translation integration. Works pretty reliable. Most view & edit form issues fixed. Nested paragraphs support - which was pretty pain in the ass. I've followed https://drupal.stackexchange.com/questions/227510/how-to-translate-parag... guide as starting point. Based on paragraphs with patch: https://www.drupal.org/files/issues/paragraphs-entity_translation-245267.... Latest patches probably not supported, but I didn't need those.

Please let me know if it's working for you, than I'll add automatic tests for it and add other features like supporting other entities than node as parent entity.

Cheers!

Added patch #146 into #170

.

Can anyone test it? More info: https://www.drupal.org/project/paragraphs/issues/2452675#comment-12654419

Hi,
Tried your latest patch, on new translation save, it produces errors

Notice: Trying to get property of non-object in ParagraphsItemEntity->save() (line 446 of ParagraphsItemEntity.inc)

It seems that for newly created paragraphs translation, it's being checked for previous languages when there isn't one, I added a check isset to the original: isset($hostEntity->original) before assigning the original langauge.
That seems to fix it.

That is:
Change line 446 ParagraphsItemEntity.inc
There is prob a better or cleaner way, this is more of a concept on the error and a quick patch.

if(isset($hostEntity->original)){
        $old_source_language = $hostEntity->original->language;
      }else{
        $old_source_language = '';
      }

Scenario,
Created node 1 with English paragraphs
Click on translate, and add new translation for node 1.
On first save for this new translation, errors, though translations are saved. On subsequent edits, no errors.

After doing the check, no errors. This is for patch #179

@tinli thanks for your work and feedback. I was able to get rid off all warnings. However I have problem with built-in paragraphs tests. I've enable test feature and use it for manual testing and everything work. Fields IDs seems also same as in the code. I'm uploading the patch to check if here also tests will fail.

@tinli since tests passed here can you test it more? Especially case with nested paragraphs.

Hello,

I just did a quick code review on the style.

1. +++ b/ParagraphsItemEntity.inc
   @@ -399,6 +401,91 @@ class ParagraphsItemEntity extends Entity {
   +      $field_names = array_keys(field_info_instances($this->entityType(), $this->bundle()));
   

   This line is too long and can be split in multiple lines. (multiple places)

2. +++ b/ParagraphsItemEntity.inc
   @@ -399,6 +401,91 @@ class ParagraphsItemEntity extends Entity {
   +          if ($field_language <> $host_language) {
   

   use !== instead of <> (multiple places)

3. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,120 @@
   +
   

   Empty line not needed. (multiple places)

4. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,120 @@
   +    // Avoid content deletion when user change language on untranslated node.
   

   I would separate with an empty line code paragraphs with a comment.

5. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,120 @@
   +      unset($originalTranslation['entity_id']);
   +      unset($originalTranslation['revision_id']);
   

   I would group those two unset in one:

   unset($a, $b);
   

6. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,120 @@
   +  public function getLanguage() {
   

   Do you think it would be possible to add the documentation header of each method and the proper return type?

7. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,120 @@
   +    return $this->hostEntityHandler ? $this->hostEntityHandler->getLanguage() : parent::getLanguage();
   

   This line is too long and can be split.

   return $this->hostEntityHandler ?
     $this->hostEntityHandler->getLanguage() :
     parent::getLanguage();
   
   

8. +++ b/paragraphs.field_widget.inc
   @@ -698,6 +721,17 @@ function paragraphs_field_widget_embed_validate($element, &$form_state, $complet
   +    if ($element['#entity_type'] != 'paragraphs_item') {
   

   I would use !== as much as possible.

9. +++ b/paragraphs.module
   @@ -860,6 +881,40 @@ function paragraphs_field_delete_revision($entity_type, $entity, $field, $instan
   +  if (isset($field_state['entity'])) {
   

   I would not enclose the main code into the condition.

   I think it would be much better to do an early return and move out the code from the condition.

   if (!isset($field_state['entity'])) {
     return;
   }
   
   // main code here
   
   

10. +++ b/paragraphs.module
    @@ -1398,6 +1399,40 @@ function paragraphs_features_api() {
    +  if (!empty($form['#paragraphs_translation_fields'])) {
    

    I would move the main code out of the if and use an early return.

11. +++ b/paragraphs.module
    @@ -1398,6 +1399,40 @@ function paragraphs_features_api() {
    +  if ($type == 'paragraphs_item' && module_exists('entity_translation')) {
    

    I would move out the code from the if and use an early return as well.

Beside that, nice work! Let's get this thing done!

Thanks a lot @pol for support. I think I've fixed most of it. I'm not sure about whole documentation changes inEntityTranslationParagraphsItemHandler class, because I'm not author of most of the code there (derived from https://www.drupal.org/files/issues/paragraphs-entity_translation-245267...). Maybe contributor will want to update documentation also. Cheers guys!

Beside that I was trying to implement tests for it. I have an error upon running paragraphs_entity_translation tests. Basically tests are not able to even start due an error:

Exception: Cannot initialize entity translation path variables (invalid path scheme). in EntityTranslationDefaultHandler->initPathVariables() (line 1737 of /var/www/drupalvm/drupal/web/sites/all/modules/contrib/entity_translation/includes/translation.handler.inc).

So I guess something is wrong with my exported feature with i18n functionality. However when I deploy this feature on 7 fresh installation I'm able to perform test scenario manually without any issues.

Could someone check it also? I'm uploading package my current state of paragraphs with this test module.

Hi,

Thanks for the fixes, I did another review.

1. +++ b/ParagraphsItemEntity.inc
   @@ -399,6 +401,95 @@ class ParagraphsItemEntity extends Entity {
   +          $field_language = field_language($this->entityType(), $this, $field_name);
   

   Split into multi-line.

2. +++ b/ParagraphsItemEntity.inc
   @@ -424,7 +515,7 @@ class ParagraphsItemEntity extends Entity {
   +        $host_entity->{$this->field_name}[$this->langcode][] = array('entity' => $this);
   

   This should be on multi-line as well.

3. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +      parent::__construct('paragraphs_item', $entity_info, $entity);
   

   Does this mean that parent constructor could be called twice then?

4. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +      if ($host_entity_type == 'paragraphs_item') {
   

   use ===

5. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +      $this->hostEntityHandler = entity_translation_get_handler($host_entity_type, $this->hostEntity);
   

   Split into multi-line.

6. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +    return $this->hostEntityHandler ? $this->hostEntityHandler->getLanguage()
   +      : parent::getLanguage();
   

   Even if this is technically perfectly valid, I would do this on 3 lines instead of two for readability.

7. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +    return $this->hostEntityHandler ? $this->hostEntityHandler->getFormLanguage()
   +      : parent::getFormLanguage();
   

   Same here.

8. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,165 @@
   +    return $this->hostEntityHandler ?
   +      $this->hostEntityHandler->getSourceLanguage() :
   +      parent::getSourceLanguage();
   

   This is perfect.

9. +++ b/paragraphs.field_widget.inc
   @@ -406,7 +412,7 @@ function paragraphs_field_widget_form_build(&$form, &$form_state, $field, $insta
   +    $paragraph_item->setHostEntity($element['#host_entity_type'], $element['#host_entity'], $langcode, FALSE);
   

   Split into multi-line.

10. +++ b/paragraphs.field_widget.inc
    @@ -425,7 +431,7 @@ function paragraphs_field_widget_form_build(&$form, &$form_state, $field, $insta
    +      $paragraph_item->setHostEntity($element['#host_entity_type'], $element['#host_entity'], $langcode, FALSE);
    

    Split into multi-line.

11. +++ b/paragraphs.field_widget.inc
    @@ -457,6 +463,23 @@ function paragraphs_field_widget_form_build(&$form, &$form_state, $field, $insta
    +      if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $paragraph_item->bundle)) {
    ...
    +      if (module_exists('entity_translation') && entity_translation_enabled('paragraphs_item', $paragraph_item->bundle)) {
    

    These are the same conditions and can be simplified.

    First, check if the module exists.
    Then inside that first condition, add the other conditions.

12. +++ b/paragraphs.module
    @@ -851,11 +872,47 @@ function paragraphs_field_delete($entity_type, $entity, $field, $instance, $lang
    +  if ($entity_type != 'paragraphs_item') {
    

    use !==

13. +++ b/paragraphs.module
    @@ -851,11 +872,47 @@ function paragraphs_field_delete($entity_type, $entity, $field, $instance, $lang
    +  if (isset($field_state['entity'])) {
    

    Use the inverse condition and use early return here as well.

    if (!isset($field_state['entity'])) {
      return;
    }
    

14. +++ b/paragraphs.module
    @@ -1398,6 +1401,46 @@ function paragraphs_features_api() {
    +  if ($type !== 'paragraphs_item' || !module_exists('entity_translation')) {
    

    I would invert the condition. First check if the module exists (or not), then check the type.

Thanks @pol, patch updated.

Hello,

Thanks for your responsiveness. I made another quick review, there is still some stuff to fix before submitting it to the maintainer.

I might be picky on the code-style but as we are going to rewrite some parts, let's do it right and use the Drupal coding standard ;-)

Thanks!

1. +++ b/ParagraphsItemEntity.inc
   @@ -399,6 +401,95 @@ class ParagraphsItemEntity extends Entity {
   +        if (isset($field['translatable']) && $field['translatable']) {
   

   We could simplify the foreach and use the inverted condition here.

   $field += array('translatable' => FALSE);
   if ($field['translatable'] === FALSE) {
     continue;
   }
   
   // Main foreach code here.
   
   

2. +++ b/ParagraphsItemEntity.inc
   @@ -514,6 +607,16 @@ class ParagraphsItemEntity extends Entity {
   +      global $language_content;
   

   I think it would be better to use the $GLOBALS variable.

3. +++ b/ParagraphsItemEntity.inc
   @@ -564,4 +667,16 @@ class ParagraphsItemEntity extends Entity {
   +    return array_keys($instances);
   

   Always have an empty line before the return statement.

4. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,168 @@
   +      parent::__construct('paragraphs_item', $entity_info, $entity);
   

   I think there is still room for improvements here.

   If the module entity_translation doesn't exist, then the call to the parent is made twice.

5. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,168 @@
   +      if ($activeLanguage == LANGUAGE_NONE &&
   

   Use ===

6. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,168 @@
   +        unset($originalTranslation['entity_id'], $originalTranslation['revision_id']);
   

   Split this into 2 lines.

7. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,168 @@
   +    return $this->hostEntityHandler ? $this->hostEntityHandler->getLanguage()
   

   Let's be consistent and use 3 lines instead of 2. Just like you did after.

8. +++ b/paragraphs.module
   @@ -1398,6 +1408,47 @@ function paragraphs_features_api() {
   +    drupal_array_set_nested_value($form, array_merge($address, array('#multilingual')), TRUE);
   

   The line is longer than 80 chars. Please split the line.

9. +++ b/paragraphs.module
   @@ -1398,6 +1408,47 @@ function paragraphs_features_api() {
   +    $et_handler->setOriginalLanguage($et_handler->hostEntityHandler->getLanguage());
   

   The line is longer than 80 chars. Please split the line.

@pol thanks for the patient, another update

Hello,

Here's a quick code review.

Could you please make sure to check the Drupal coding standard and fix the logic issue with the parent constructor called twice on some cases ?

thanks!

1. +++ b/ParagraphsItemEntity.inc
   @@ -102,25 +102,29 @@ class ParagraphsItemEntity extends Entity {
   +
   

   Please, remove any empty line after the start of the function.

2. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,172 @@
   +
   

   Extra empty line.

3. +++ b/includes/translation.handler.paragraphs_item.inc
   @@ -0,0 +1,172 @@
   +      parent::__construct('paragraphs_item', $entity_info, $entity);
   

   Still the same issue. If the module entity_translation doesn't exists, then, the parent class constructor is called twice on the same parameters.

4. +++ b/paragraphs.field_widget.inc
   @@ -457,6 +471,26 @@ function paragraphs_field_widget_form_build(&$form, &$form_state, $field, $insta
   +        if (empty($form['#paragraphs_translation_fields']) || !in_array($address, $form['#paragraphs_translation_fields'])) {
   ...
   +        $language = entity_language($element['#host_entity_type'], $element['#host_entity']);
   

   Line longer than 80 chars. Please, make sure that your changes are following the drupal coding standard... see: https://www.drupal.org/docs/develop/standards/coding-standards#linelength

5. +++ b/paragraphs.module
   @@ -1398,6 +1408,49 @@ function paragraphs_features_api() {
   +  return "";
   

   Use single quotes.

6. +++ b/paragraphs.module
   @@ -1398,6 +1408,49 @@ function paragraphs_features_api() {
   +    $merged = array_merge($address, array('#multilingual'));
   

   I would not create the $merged variable.

   I would write this:

   drupal_array_set_nested_value(
     $form,
     array_merge($address, array('#multilingual')),
     TRUE
   );
   

7. +++ b/paragraphs.module
   @@ -1398,6 +1408,49 @@ function paragraphs_features_api() {
   +    $et_handler->hostEntityHandler->getLanguage() != LANGUAGE_NONE)
   

   Use !==

@pot could you send a guide how you configured phpcs in PHPStorm? Seems I'm missing some warning.

I don't understand why contructor can be called twice.

The code is basically:

class EntityTranslationParagraphsItemHandler {

     public function __construct($entity_type, $entity_info, $entity) {
       if (!module_exists('entity_translation')) {
         parent::__construct('paragraphs_item', $entity_info, $entity);
       } else {
         // Other code.
         parent::__construct('paragraphs_item', $entity_info, $entity);    
       } 
    }
}

I don't see the issue (call parent more than once) in the code.

Final patch from my side, I've no time to fix more code formatting things.

Hello,

Sorry for the point 3 in #195, I was not seeing it properly in dreditor.
I applied the patch locally and all good.
I modified a bit the code style and didn't change the logic.

Thanks!

@pot thanks a lot for support.

Hello,

I found a bug with translation delete for cases when paragraph field is multiple. For example host entity contains 3 paragraph entities (deltas are 0, 1 and 2).

Expected result: translations are deleted for each paragraph entity on translation delete of host entity

Actual result: translations are deleted only for paragraph with delta = 0.

It happens because:
All paragraphs have the same host entity. It's ok. But let's see method EntityTranslationDefaultHandler::saveTranslations (https://cgit.drupalcode.org/entity_translation/tree/includes/translation...). $translations is an object and as we know objects are passed by references by default and after call $translations->hook = array(); (https://cgit.drupalcode.org/entity_translation/tree/includes/translation...) any other paragraph entities with delta != 0 can't pass this condition https://cgit.drupalcode.org/entity_translation/tree/includes/translation...

I fixed a bug and code styling.
Patch attached.

Hello,

Thanks for the feedback.

Could you reroll your patch and please do not change the code styling. We've passed hours to review and provide an update.

Thanks!

Patch without changes of code style.

PS: I don't understand, why you changed code style in some functions, which not related with issue, for example:

1. @@ -811,7 +832,7 @@ function paragraphs_field_update($entity_type, $entity, $field, $instance, $lang
     * Implements hook_field_delete().
     */
    function paragraphs_field_delete($entity_type, $entity, $field, $instance, $langcode, &$items) {
   -  if ($field['type'] == 'paragraphs') {
   +  if ($field['type'] === 'paragraphs') {
   

2. @@ -849,17 +870,61 @@ function paragraphs_field_delete($entity_type, $entity, $field, $instance, $lang
     * Implements hook_field_delete_revision().
     */
    function paragraphs_field_delete_revision($entity_type, $entity, $field, $instance, $langcode, &$items) {
   -  if ($field['type'] == 'paragraphs') {
   +  if ($field['type'] === 'paragraphs') {
        foreach ($items as $item) {
   -      if (!empty($item['revision_id'])) {
   -        if ($paragraphs_item = paragraphs_item_revision_load($item['revision_id'])) {
   -          $paragraphs_item->setHostEntity($entity_type, $entity, $langcode, FALSE);
   -          $paragraphs_item->deleteRevision(TRUE);
   -        }
   +      if (!isset($item['revision_id']) || empty($item['revision_id'])) {
   +        continue;
   +      }
   +
   +      if ($paragraphs_item = paragraphs_item_revision_load($item['revision_id'])) {
   +        $paragraphs_item->setHostEntity(
   +          $entity_type,
   +          $entity,
   +          $langcode,
   +          FALSE);
   +
   +        $paragraphs_item->deleteRevision(TRUE);
   

@zestagio thanks for the fix. I know that a code style changes in not related functions may be annoying in patch scope, but it was for cleaning some code also in the meantime. Now much more important is adding a tests for i18n feature.

Can you write test steps for your case?

Also I suggest this kind of refactoring (not tested), if you don't mind:

  public function getTranslations() {
    if ($this->hostEntityHandler) {
      return clone $this->hostEntityHandler->getTranslations();
    }
    return clone parent::getTranslations();
  }

Btw can you explain purpose of cloning more to me?

@codium,

see #2452675-201: Entity translation support for Drupal 7. I described a problem there.

@zestagio, got it. Thanks

All work fine for me except two things

1) After save the node with paragraphs I get this error twice when view or edit the node. The same appears after applying the patch and trying to add a paragraph, but it was fixed after drush rr #104. Rebuild only fix the error when try to add a paragraph, the error in view and edit node still there.

Notice: Undefined property: stdClass::$original in EntityTranslationParagraphsItemHandler->__construct() (line 60 of /Applications/MAMP/htdocs/pruebas/sites/all/modules/contrib/paragraphs/includes/translation.handler.paragraphs_item.inc).

2)paragraph_item in the table entity_translation is not deleted when delete the node. I report and fix this before in #158, but maybe is not the proper way

Thanks

Sorry, the error was not duplicated, they are two different errors

Notice: Undefined property: stdClass::$original in EntityTranslationParagraphsItemHandler->__construct() (line 60 of /Applications/MAMP/htdocs/pruebas/sites/all/modules/contrib/paragraphs/includes/translation.handler.paragraphs_item.inc).

Notice: Trying to get property of non-object in EntityTranslationParagraphsItemHandler->__construct() (line 60 of /Applications/MAMP/htdocs/pruebas/sites/all/modules/contrib/paragraphs/includes/translation.handler.paragraphs_item.inc).

Sorry again,

Swapping the lines 60 and 61 solve the problem 1

// before
$this->hostEntity->original->language !== $activeLanguage &&
isset($this->hostEntity->original) &&

// after
isset($this->hostEntity->original) &&
$this->hostEntity->original->language !== $activeLanguage &&

For the problem 2 I don't see any function to delete the paragraph items in the tablesentity_translation and entity_translation_revision when delete a nodes or paragraphs.

Could be something like this:

/**
 * Implements hook_entity_delete().
 */
function paragraphs_entity_delete($entity, $type) {
  if ($type == 'paragraphs_item') {
    foreach (array('entity_translation', 'entity_translation_revision') as $table) {
      $res = db_delete($table)
        ->condition('entity_type', $type)
        ->condition('entity_id', $entity->item_id)
        ->execute();
    }
  }
}

Problem 3, in the edit form and trying to add a nested paragraph appear empty, no fields, even with and without translatable fields.

The patch in #136 work with nested paragraphs. I use this patch in several projects, for example www.miamismith.com and www.focalyx.com

@RAFA3L do you have paragraph reference field translatable or not?

Not, the paragraph field in node is not translatable and fields inside paragraph are translatable