Support Field Collection field types

We don't provide field collection specific integration yet. And field collections' entity_translation integration is AFAIK not really working correctly yet.

How is your structure exactly? Are you using content or entity translation? If entity translation, is your field collection marked as translatable and it creates a field collection per language or is the field collection field untranslatable but has translatable field within it?

If you're using content translation or a translatable field collection field, then you will have to implement hook_tmgmt_source_translation_structure() and hook_tmgmt_field_type_populate_entity() for field_collection, recursively extract the fields with tmgmt_field_get_source_data() in the first hook, return them and then, when you get the translation of those fields, create a new or update an existing field collection for the target language.

TMGMT supports any kind of nested data item structure, although nobody has really tested it so far with something deeper than 3, might run into some problems with a certain depth due to the string length.

Would be great if you can start this.

Make sure to first check the multilingual workflows with manual translations added through the UI.
Make sure, the modules natively deal with this right.

(because TMGMT source plugin just remote controls all this...)

Then you know if, the original modules need multilingual fixes first, or if it is just integrating the (working) logic with the tmgmt source plugin.

This is related to #1495130: Related source suggestions

Updated issue summary.

I see you even need to modify the importer to support field_collections. I'm not so happy with the approach chosen here and i hope that we can support this export / import better. Please add more description to the code fragments about why and what kind of effect you intend.

In general, supporting major contribs such as field collections is something we love to add to the TMGMT core.
But in order to add extra features, we need test coverage.

Can you please add a test to show what case / configuration you exactly support?
I also see some commented-out code in the code that needs explanation:
http://drupalcode.org/sandbox/Vic/2104675.git/blob/refs/heads/master:/tm...

  35       if (/* (!$only_translatable || $sub_field['translatable']) &&  */$items) {

Uh.. Sandbox needs work.

I'm fine with adding that to tmgmt core, happy to review patches.

Some quick notes:
- hook_init() shouldn't be necessary, make sure your class files are added to files[]
- .module and .info don't have the same name, that shouldn't work?
- When providing a patch, add your changes to html file plugin directly instead of overriding the class, I'm not sure what exactly you changed there.

I am unclear how this relates to #1999802: Related source suggestions for field collections - this is translating field collections "directly" as entities (and using entity_translation), rather than as related sources? It seems that treating them as independent entities may - for sites that are not 100% translated - make it hard to identify which ones need translation (i.e. which parent entities have which language translations).

Yes, that is exactly the idea. Fields of the field collection would get added (recursively, if the field collection has other field collections attached).

As stated above, the sandbox module needs work, but should conceptually work. We might also discover some issues in our UI's with this, although we tried to be ready for cases like this in e.g. the review UI.

Would be great if someone can push it further :)

Updated issue summary.

Hi everyone.

Since miro_dietiker thinks this would be a good addition to the core tmgmt module, I've converted the field_collection part of the sandbox to a patch. The code remains mostly the same as it is in the sandbox module. I've cleaned up comments, made coding standards changes, and removed that line of commented-out code, which I don't believe is necessary. It was attempting to check whether an individual field within the field collection should be translated, instead of just passing that responsibility to the field translation source plugin, which I think is a preferable way to do it.

I put the hooks in an include file within the field source pugin. Seems to make sense to me since it's technically a type of field, and mostly just ends up passing the processing to the tmgmt_field module itself. Let me know if you don't think this organization is the best.

A test is still needed, as pointed out in #6. But here's a start. Seems to work well for me locally (note that a field_collection patch is also required to get translation working: #1316162: Support content translation and host entity cloning).

13: tmgmt-field_collection-1973510-13.patch queued for re-testing.

13: tmgmt-field_collection-1973510-13.patch queued for re-testing.

Thank you for the update.

We ran into problems of multilingual support of field collection and are eagerly awaiting it to get committed.
I would suggest to wait with this feature till field collection finally decides to commit multilingual support.

Working on tests meanwhile is still encouraged.

I test #13 but run into an issue. The export does not translate the content of the field collection, it changes it for every language.
For example:

English to German text field inside field collection
This is my test -> Das ist mein Test

Every content changes to "Das ist mein Test" and not only the german.

EDIT: I downloaded and installed the sandbox module tmgmt extra and it seems to work, are there any know issues with this sandbox module?

What is the status on this? Since #1316162: Support content translation and host entity cloning has been committed, can we start working on this issue?

Lukas, we are working hard on the 8.x branch of TMGMT. 7.x is not our feature focus.

We could still add support for Field Collections in TMGMT. The strict requirement for it is proper test coverage and positive feedback of the community using the code proposed. Thus switching to "needs work".

Keep in mind though that the multilingual issue from field collection is not fully fixed. Read the comments carefully and search for followups created.

Yes, I know.

Can you please tell me which followups are Field Collection translation issues relevant for this? Is #1344672: Field Collection: Field translation (entity_translation) support. the only one?

What translation methods are supported in the patch? Content translation, field translation or both?

I need this feature on a project soon and sponsoring is possible. Anyone? :)

Anyone holding onto any patches for this that they have not uploaded? :)

We might wind up trying to add support for FCs. They are crucial for us.

We will look into this issue.

First we will test some scenarios including nested field collections (where the parent is not translatable, but the child is)...
And then provide an update.

If it looks like we can make this work (or or clearly describe the limitations and they are acceptable), we will complete test coverage and get this in.

For Drupal 8 though, we will skip implementing this, as the direction of the debate is to deprecate Field Collections and recommend the usage of Paragraphs (which is perfectly TMGMT integrated already! Yay!)

I've added a test, might still need some clenup.

Meh, wrong patch.

Apparently the patch works fine with the latest dev of field collection but not the latest tagged release (beta11). I created an issue over there: #2803735: New tagged release beta13 I think postponing this until then makes sense.

We have a release!

Woot :-) will commit later.

Committed, party! :-)

Not marking as needs port to 8.x-1.x due to #2784931: Proposal: Deprecate Field Collections for Drupal 8, focus on Entity Reference Revisions & Paragraphs