Translation support in vertical data aggregation

Took a first shot at what I outlined in the summary.
Is missing tests for now - will do some manual testing for our scenario first.

I support your approach. I don't have time to test such a thing right now but I'll try to next week. I reviewed the code though and it looks very good!

Merged.

Does this make ✨ Make external entities translatable Needs work obsolete?

(just FYI: we've been using the work in ✨ Make external entities translatable Needs work successfully on a large project for a few months now)

I'm not sure as I am not currently dealing with multiple languages so I can' tell (it's far in my stack but it's there).
I'll let @das-peter answer if he passes by, but to give more info in case he does not, this patch allows to aggregate multiple language version of a content into one external entity instance.

So, let's say you use a REST client that gather content from a website and that content site provides 2 endpoints, one for English and one for French. Each content item has the same id on both endpoint but its content is in different language for each endpoint. You use the vertical aggregator with 2 REST clients, one for each endpoint, and you aggregate them using the new option "as a translation" for the second client. Then you are supposed to have a drop-down letting you choose the language corresponding to the client endpoint and it will add the translated content as a sub-field of the external entity instance. Your xntt array would look something like that, more a less:

[
  'id' =>  1234,
  'title' => 'Some title',
  'content' => 'Some content in English.',
  '__external_entity_translation__fr' => [
    'id' =>  1234,
    'title' => 'Un titre',
    'content' => 'Du contenu en français.',
  ],
];

...that's what I understood so far.

@rp7 Darn, how didn't I see that MR. Sorry about that.

@guignonv I think you covered it pretty much.
This change here allows you to dynamically combine the translations of different requests into single entity.

So you got
https://www.dummy.com/de/jsonapi/node/publication?filter[id]=d4133e27-92a8-40c9-9b57-122494e444c5 that returns

{
  "data": [
    {
      "type": "node--publication",
      "id": "d4133e27-92a8-40c9-9b57-122494e444c5",
      "links": {
        "self": {
          "href": "https:\/\/www.dummy.com\/de\/jsonapi\/node\/publication\/d4133e27-92a8-40c9-9b57-122494e444c5?resourceVersion=id%3A464359"
        }
      },
      "attributes": {
        "drupal_internal__nid": 106017,
        "langcode": "de",
        "status": true,
        "title": "TITLE DE"
      }
    }
  ]
}

And then https://www.dummy.com/de/jsonapi/node/publication?filter[id]=d4133e27-92a8-40c9-9b57-122494e444c5 that returns

{
  "data": [
    {
      "type": "node--publication",
      "id": "d4133e27-92a8-40c9-9b57-122494e444c5",
      "links": {
        "self": {
          "href": "https:\/\/www.dummy.com\/fr\/jsonapi\/node\/publication\/d4133e27-92a8-40c9-9b57-122494e444c5?resourceVersion=id%3A464359"
        }
      },
      "attributes": {
        "drupal_internal__nid": 106017,
        "langcode": "fr",
        "status": true,
        "title": "TITLE FR"
      }
    }
  ]
}

which is combined into a single entity.

Does this make #3476326: Make external entities translatable obsolete?

I don't think so actually. That MR seems to "hope" for already structured data in the response of the REST Endpoint.
So you got https://www.dummy.com/jsonapi/node/publication?filter[id]=d4133e27-92a8-40c9-9b57-122494e444c5 that returns:

{
  "data": [
    {
      "type": "node--publication",
      "id": "d4133e27-92a8-40c9-9b57-122494e444c5",
      "links": {
        "self": {
          "href": "https:\/\/www.dummy.com\/jsonapi\/node\/publication\/d4133e27-92a8-40c9-9b57-122494e444c5?resourceVersion=id%3A464359"
        }
      },
      "de": {
        "attributes": {
          "drupal_internal__nid": 106017,
          "langcode": "fr",
          "status": true,
          "title": "TITLE FR"
        }
      },
      "fr": {
        "attributes": {
          "drupal_internal__nid": 106017,
          "langcode": "fr",
          "status": true,
          "title": "TITLE FR"
        }
      }
    }
  ]
}

And the raw data are "split" into the translations of a single entity.

I cheekingly say "hope" above because I don't think that MR currently allows you to map the language data but the provided data has to match or brought into the expected format.
I'd love to see a language data mapping which would allow to map the language data, with whatever langcode is used, to the "magic" translation keys "__external_entity_translation__fr".
So that a config like the following then would lead to the __external_entity_translation__* keys being populated:

• Language Map De: $.data.de
• Language Map FR: $.data.fr

Another option would be if the data requested come like:

{
  "data": [
    {
      "type": "node--publication",
      "id": "d4133e27-92a8-40c9-9b57-122494e444c5",
      "links": {
        "self": {
          "href": "https:\/\/www.dummy.com\/jsonapi\/node\/publication\/d4133e27-92a8-40c9-9b57-122494e444c5?resourceVersion=id%3A464359"
        }
      },
        "attributes": {
          "drupal_internal__nid": 106017,
          "status": true,
          "title": {
              "de": "TITLE DE",
              "fr": "TITLE FR",
          }
        }
    }
  ]
}

I think one could somehow work out a mapping here too.
Something like $data[*].attributes[*].de but that might need another merge mode too :|

Note: the second query should be corrected as it uses "de" instead of "fr". ;)
https://www.dummy.com/fr/jsonapi/node/publication?filter[id]=d4133e27-92a8-40c9-9b57-122494e444c5

Automatically closed - issue fixed for 2 weeks with no activity.