incorrect docs for EntityContentBase 'translations' configuration option

Input from @mikelutz on Slack:

> On the technical side, it does 2 things. It adds the langcode as a destination id, and on the import side makes sure that you are creating or updating a translation of an existing entity, instead of trying to create a new entity or attempting to change the base language of an existing entity.

> It’s real purpose is to add the langcode as an ID and to update a translation instead of trying to update the base entities langcode. As such, with the old style migrations, you would migrate the base translations first, without setting translations to true, and then migrate the translations in a separate migration that looks up the node ids of the original translations and wants to update/add a translation of that, so we would set translations:true for that one.

> It is possible to migrate all base languages and translations in one shot with a source that has the right configuration using one migration with translations:true, but core didn’t do it that way.

Some of the above needs to be picked out and used for fixing the docs.

Core maintainers: please add credit for @mikelutz.

smustgrave → credited mikelutz → .

Re-ran test failures and as expected random.

Reading the change and to me in reads just fine. Believe should be good.

I don't think this should remove the point that 'translations' "indicates if the entity is translatable".

@quietone, I'll make the necessary changes suggested in the comments.

@quietone
I made the suggested changes in the documentation
Please take a look

I also rebased the fork to the latest changes
Please take a look

Rebased the fork to the latest changes

Pipeline run and passed with no errors or warnings

Feedback appears to be addressed.

> I think this should be process pipeline instead of process definition because the pipeline consists of many process plugins.

No, it shouldn't be 'process pipeline'.

The definition of the term pipeline is this:

> Each step uses a single process plugin, and a chain of process plugins is called a pipeline.

In the MR, we don't mean a single pipeline, we mean the entire 'process' definition of the migration.

So should I change the "process pipeline" back to "process definition" in the docs?

Changed the "process pipeline" back to "process definition" in the docs as per #15.
Please review

Think there is still discussion going around the wording.

@joachim is correct here. The migration process definition is everything under the `process` key in the migration yaml, which is what the instructions are referring to. The process definition consists of multiple mappings of destination keys to process pipelines, and each pipeline consists of multiple process plugins.

In this context, the statement "... the migration process definition must include mappings for the entity ID and the entity language field." is correct. Replacing the word 'definition' with 'pipeline' would not make sense, as the migration has several process pipelines, one for each process definition mapping.

To be fair though, while this is the technical nitpicky definition, we are fairly inconsistent in the way we use these terms in internal discussions. THe maintainers often rely on context to determine exactly what is being talked about, and I wouldn't be surprised to dig through and find inconsistencies in the documentation too.

Anyway, I believe this issue is good to go.

@mikelutz, thanks. I was mistaken.

Committed to 11.x and cherry-picked to 11.1.x.

Thanks!

quietone → closed merge request !9786

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