[meta] Translate unpublished node (revision) / Content moderation integration

What you're asking for is support for forward revisions, doesn't matter if they are published or not (they actually are published, they're not just not the default revision).

And no, unfortunately we currently have no support for that yet. There has been an issue for 7.x with #2642018: Allow alternative methods for selecting revisions but that got stuck.

We might have a project soon with a possible partner to implement something, but it's not official yet.

*Raising hand*

I'll need it also, and I may be able to put someone on it.

Interesting. Can you explain a bit what your exact requirements/desired workflows are?

Our plan was to be able to configure somehow/somewhere if you want to translate the latest revision or default revision and when accepting a translation, again being able to configure if it should update the revision or create a new one.

I guess we could do a chat or so to discuss/define how we want to approach this, it's not a trivial task.

Right our needs might be a bit specific and it may or may not be related to workspace/deploy (depending on the direction we'll take).

Essentially we want to use Drupal as the content repository for the translation of strings in some of our apps. In our apps we use feature branches and we might want to be able to have "work in progress" branches and strings sent to translation.

I'm sure we could do it another way but we're trying to keep our content folks in just one tool.

Our user story for this feature would be:
As a content editor I want to update a page, leave it in draft, and send it for translation.
WHEN I update content on a page and
WHEN I save the page as a draft
THEN I send that draft to be translated
WHEN the translations come back they are saved as new drafts to the translation
THEN I can schedule all translations for publish at the same time.

@nod_ if you add a translator to the game with translation memory then it doesn‘t matter too much for the workflow if software revisions are entity branches / pending revisions or even separate entity instances. They can be easily autopopulated.

A memory is needed anyway to deal with updates like @AMDandy described to avoid annoying translators or challenging reviewers because we get inconsistent translations with an update and avoid double spending. I like this as a simple reference story.

One question would be if we should still attach the previous translation to an xliff translation export. Due to changes, this could lead to inconsistend xml object tree (source VS target) that is incompatible with many tools..

Yes, so questions with that user scenario:

1. Should we always use the latest revision? Should it be configurable globally? I'm considering to just always doing it, which is consistent with how /latest and /edit are working now in HEAD.

2. What about saving a translation? Right now we update the same revision although content_moderation is likely overriding that if enabled? Maybe we should just always respect the new revision setting of the target entity type? That is only available for some, but it's better than nothing. Or a setting? Or just always do it? Maybe respect the setting and default to a new revision (if the target supports revisions, of course)?

> One question would be if we should still attach the previous translation to an xliff translation export. Due to changes, this could lead to inconsistend xml object tree (source VS target) that is incompatible with many tools..

That's always true, irrelevant of revisions, I think doing or not doing that is not relevant for this issue.

1. It makes sense for our use case that translations would always be sent for the latest revision.

2. Likewise, it also makes sense that a new revision would be created when saving a translation since saving creates a new revision if that entity supports revisions.

Hello! I'm working on integrating this great module on one of our sites. First I want to ask if there is an estimate on when we hope to have this issue/feature solved/implemented? I've read that there are plans to start working on this "soon". I want to know because depending on the ETA our organization might decide to do some things differently in the short term regarding how we'll try to implement our desired workflow.

Part of our use case is as follows:
As a content editor I want to be able to send a Draft for translation. Once the translation is back I want to be able to review the changes in an unpublished draft and schedule a date for when the Draft with the translation is supposed to be published.

I'm not very familiar with insides of the module yet but I'd be happy to help out in this issue any way I can.

I expect that we'll start with this in the next weeks. Will update this once we started.

About your use case.

> As a content editor I want to be able to send a Draft for translation.

Would your expectation also be if there is a pending draft revision in the selected language, it should *always* use that and not the currently published that? Or would you expect a setting, either globally or when selecting the source (the last option would be considerably more complicated than a global setting).

> Once the translation is back I want to be able to review the changes in an unpublished draft
I guess this would at least need to be configurable globally if not per job item when accepting it.

> schedule a date for when the Draft with the translation is supposed to be published.
This is outside the scope of TMGMT, you will need to use other modules like https://www.drupal.org/project/scheduled_updates for that. Once you accepted the job item, everything that happens that is no longer in our control.

> As a content editor I want to be able to send a Draft for translation.

Would your expectation also be if there is a pending draft revision in the selected language, it should *always* use that and not the currently published that? Or would you expect a setting, either globally or when selecting the source (the last option would be considerably more complicated than a global setting).

Our project owner hasn't specified either one of the scenarios explicitly but I believe that the simpler solution would be sufficient for their immediate needs. What would be helpful for our use case would be to be able to decide on the behavior at the Job level.
To flag it whether it should be something like:

1. Imported as a new unpublished draft
2. Imported as a new revision with the same state as the current state of the source.
3. Imported as a new published revision.

> Once the translation is back I want to be able to review the changes in an unpublished draft
I guess this would at least need to be configurable globally if not per job item when accepting it.

I think for our content editors this could also be outside the scope of TMGMT. If the translation could be imported into an unpublished draft the editor would be able to "review" as in preview the content as usual, and schedule the node to be published at a later time or publish it directly.

> schedule a date for when the Draft with the translation is supposed to be published.
This is outside the scope of TMGMT, you will need to use other modules like https://www.drupal.org/project/scheduled_updates for that. Once you accepted the job item, everything that happens that is no longer in our control.

I agree. This would also "just work" if the translations were imported in an unpublished Draft.

Ok, we are starting with the implementation here.

I'm converting this to a meta issue and feature request.

As a first step, we will implement the following functionality in a new issue:

1. If content moderation is enabled and the entity has a pending draft in the given language, always use that as the source.
2. We use \Drupal\tmgmt\SourcePluginUiBase::reviewForm() and the related validate/submit methods to show an element above the accept buttons that allows to...
2.1: If content moderation is enabled, allows to select the desired workflow state (draft/published/...) that it will have. While we have those methods, there isn't really an official way to store this information, so my proposal would be to introduce a special key like #workflow_state or so as top-level key in the data array of the job item, then we check for that and do the necessary steps when accepting the translation.
2.2: As a fallback, if content_moderation is not enabled, we just show a Published yes/no checkbox if the entity type implements EntityPublishedInterface(), default to published unless the source is still unpublished as well.

And of course extensive test coverage for that. Entities with and without content moderation, with pending revisions on the selected source language, entities that already have translations in the target language, both as published as well as draft.

In a second step, we will likely add default settings for the published/workflow state per entity type/bundle but I'm not quite sure yet where/how, so we'll evaluate that once we have the first step done.

I created the first child issue based on #14 #2978341: Support pending revisions and accepting translation as a specific moderation state .

While on this, we should also set the entity revision log to a message referring to the original TMGMT Job.

Hello, was this request implemented into TMGMT ? if so, in which version is it available ?

The issue referenced in #18 has now been committed and will be available in the next release.