Problem/Motivation

The translation behavior added in #2494959: Add translation integration is not correct for all use cases. It completely disregards the IEF field's "translatable" setting and therefore behaves different to user expectations.

Proposed resolution

Here's my take on how I think IEF language support should work, which is also my understanding on how core handles translatable fields.

Case 1: The IEF field is not translatable.
This is the currently implemented behavior: All host translations reference the same entities.

Case 1.1: The referenced entities are not translatable.
All host translations reference the exact same entity, regardless of its language.

Case 1.2: The referenced entities are translatable.
The entities are loaded in the host entity's language (if it exists) or allow to create a translation for its language.

Case 2: The IEF field is translatable.
This is where things break. When a field is translatable, the value on one host translation is generally allowed to differ from those of another. Thus, the referenced entities may also differ (e.g. different ids, different number of values). This problem is also described in #2822764: Support adding new entities when translating.

Case 2.1: The referenced entities are not translatable.
All host translations can potentially reference different entities, regardless of their language.

Case 2.2: The referenced entities are translatable.
All host translations can potentially reference different entities. These are each loaded in the host entity's language (if it exists) or allow to create a translation for its language.

The second use case is so far not supported at all, which makes a mess on more complicated multilingual site setups. Without this language awareness the complex handler is pretty much unusable for our customers :/ The simple IEF handler seems to follow the correct behavior already.

Do you agree with these cases, or did I miss any?

Comments

ckaotik created an issue. See original summary.

johnwebdev’s picture

johnwebdev commented

I agree with the use cases. And I believe case 2 is essential as well. Just for references, here are steps to reproduce where use case 2 currently fails / not implemented.

1. I've downloaded Drupal 8.3.x-dev and latest Inline Entity Form 8.x-1.x-dev.
2. I installed with Minimal profile
3. I enabled Languages modules and added language Swedish. Now I have two languages English (default) and Swedish.
4. I create content type Foo which has translation enabled.
5. I create content type Bar which has translation enabled. I add a "Foo reference" field which has translation enabled.
6. I set Foo reference field to IEF Complex, and add setting: "Allow users to add existing nodes." only.
7. I verify that each content type has translation enabled for all fields.
8. I add a "Foo" node (English) and translates it to Swedish as well.
9. I add a "Bar" node (English) without adding any reference.
10. I translate Bar node to Swedish and cannot see IEF form at all.

rockaholiciam’s picture

rockaholiciam commented

I too believe case 2 is crucial and should be handled.

tormu’s picture

tormu commented

Is this case 3 or do you think this should be a completely new issue?

1. Node X is translatable. It has a non-translatable reference field with IEF (so each of the node X translations will have same references)
2. In node X form there's IEF Complex widget and I can edit the individual referenced content, in all translations of node X - wonderful.
3. Node Y is translatable. It has a non-translatable reference field to node X. And the Y form has this field set to be IEF complex - so it's IEF inside IEF.
4. When I edit the _original_ translation version of node Y, I can use IEF to edit the referenced node X AND the content referenced inside it's reference field - still great!
5. Then the fail: when I edit the translation of node Y, I can only use IEF to edit the referenced node X but NOT the content referenced in it.

ckaotik’s picture

ckaotik
Primary language German
Location Berlin
commented

I think Gábor Hojtsy nicely described the intended translation behavior of D8 fields on the example of taxonomy fields in Drupal 8 multilingual tidbits 17: content translation basics (external site, so just links, no embed). The paragraph is about halfway down and also provides an image explanation :)

@tormu I don't know if your issue is related. Sounds like IEF has trouble when multiple translatable entity_reference fields get nested. Might be a side effect, have you tried if any of the patches in #2747781: Entity reference translation breaks adding new parent entities in non-default languages solves your problem?

badrange’s picture

badrange commented

I just created this bug report - I wonder if it is interesting for people following this issue:
https://www.drupal.org/node/2908530

timodwhit’s picture

timodwhit commented

This feels like a dupe of #2822764: Support adding new entities when translating.

If case 1 is already how it exists, and case 2 isn't supported as of yet because it is related to asymetrical translations which is mentioned on #2822764: Support adding new entities when translating. I think we should focus our effort on moving the adding/editing translations to that ticket.

Am I missing something?

ckaotik’s picture

ckaotik
Primary language German
Location Berlin
commented

This issue is about the translation handling in general, which can mess up on various occations:
- when creating/translating/editing parent entities
- when creating/translating/editing child entities
- possibly other situations, too

To be honest, I no longer have any clue to what the vision behind "Translation in and with IEF" is. I don't think that case 1 is what is currently implemented, and case 2 definitely isn't, but I just can't concentrate on this issue at all at the moment.
Maybe someone can do some research into how IEF currently handles translation, and why this is so very much different from Core's handling.

RumyanaRuseva’s picture

RumyanaRuseva commented
Related issues: +#2901461: Show non-translatable fields instead of hiding them

All of case 2 is covered in #2822764: Support adding new entities when translating.
Case 1.1. works correctly, and case 1.2. breaks for nested inline entity forms and it's addressed in #2901461: Show non-translatable fields instead of hiding them

I suggest closing this one as duplicate of the other two issues.

lpeabody’s picture

lpeabody commented

I'd like to see this be treated as a parent issue for handling the revamp of translation adjustments to IEF. Other modules do similar parent issues as a form of "checking the boxes" so it makes it clear, in one place for everyone to see that all of the adjustments have been made and everything is release ready. Though that depends if the maintainers are interested in managing all of the translation adjustments in a single release... I dunno, my 2 cents.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: Translation behavior is broken in some use cases » (Plan) Support all 4 reference-field/child-entity translatability combinations
Category: Bug report » Plan