Content moderation options in entity translations

Raised MR !696. Added a "Translation status" setting to AI Translate config. You can now choose to keep the original entity's status or always create translations as drafts. It's a global setting for now — per-entity/bundle config can be explored later if needed. Redirect behavior setting not included in this MR.

I have review the MR.
But on translation on any option selected the translated content is saved as published. It is not keeping the currect status of the original node.

Steps followed:

1. Enabled translation for the content article.
2. Added additional language.
3. Moved the original content to draft state
4. Selected the "Keep the status of original entity" option in ai translation settings and saved.
5. tried translating article content
6. The translated content is saved as published.
8. Go back to ai trsnslation settings and change the option to "Create translation in draft status" and tried translating the content.
9. The translated content is saved as published.

Here is another approach, where 2 options are offered on-the-fly, without any need for configuration changes: Keep the original translation status, or forcibly save the translation as unpublished.

I have the same behavior as @anjaliprasannan

@efpapado: I'm afraid your approach creates an option to permission bypass, i.e. by manually adding 1 to the link, user will be able to publish an entity even if they don't have access to

Hi, adding 1 (or anything trueish) forces the translation to be saved as unpublished (TRUE => force unpublished).
Adding 0, or nothing, will just fall back to the current behaviour. If there is an access bypass issue, (I haven't checked) it is not introduced by this patch.

@efpapado: oh, I didn't realize that.
Still, I'd prefer the approach in https://git.drupalcode.org/project/ai/-/merge_requests/696 - I don't think it's the site builder who decides what is the translation flow (i.e. is the AI-translated page gets published), but the site administrators.

@valthebald:
No strong opinions, sharing thoughts:

I don't think it's the site builder who decides what is the translation flow (i.e. is the AI-translated page gets published), but the site administrators.

If someone has the permission to publish translations, why would it be different if the translations are manually added through drupal's UI, or automatically (but still, manually triggered) through a request to some AI tool?
We should just follow the normal permissions related to translating content. Would adding an extra layer of permissions/settings worth the complexity?
One might be confident enough to not require manual control and wanting to publish immediately, or might want to have a manual review first.

@efpapado: we could argue on possible reasons to change the flow, but there's more:
1. UI change - "Translate using ... " already takes significant part of the translation list screen, if we have 2 options instead of one, the screen would look like this:

This doesn't seem an improvement of UX. Maybe those options can go to the actions list (Add/Edit/Delete)?
2. More importantly, "force save unpublished" doesn't take any effect, I still get a published entity if the original entity is published.

@efpapado: there could be an option to match both flows, and this is "let the user decide" option in
AiTranslateSettingsForm::buildForm (see the second MR):

      '#options' => [
        'keep_original' => $this->t('Keep the status of original entity'),
        'create_draft' => $this->t('Create translation in draft status'),
        'user_decision' => $this->t('Let the user decide'),
      ],

but in any case, non-unpublishing the translation is the bigger target to hit

After some debugging, the reason for the status being kept as "Published" is \Drupal\content_moderation\EntityOperations::entityPresave() that checks $entity->moderation_state field but not the "published" key (which is changed indirectly.

Needs to be tested how this affects the published status of original entity (it should stay intact)