Problem/Motivation

Editorial Workflow for Translations is not possible to be assembled yet in a way similar to the Workbench moderate module.
The entity: node can have revisions, taxonomy terms are getting it, but that is not enough.

Proposed resolution

These issues together are needed to make Translation Editorial Workflow possible. (make it possible to do in contrib?)

Issues todo

Issues done

Description in words what a Translation Editorial Workflow might be like

(work in progress)
Ideally, staging translation revisions separately could be done in contrib.

When you create a new node, article for example, it can go through draft, review and to publish. Plus stay live while a new version is worked on later on. That should be possible for the translations of that same node when using the entity translation module. Nodes would have published flags, authors, etc. per language and could have separate node access.

Example goal: have enough in core that allows a contrib module to make a staging workflow so all language versions has to be reviewed and approved before any of them go live.

Remaining tasks

  • get a better title for the issue
  • review the list of meta issues, add any that are missing
  • note which are "required" or just "helpful" in making Translation Editorial Workflow possible
  • define in words what a functional workflow would be like
  • (maybe) add some issues and mark them as done, that are already committed that were critical to making this possible (provide some acknowledgment and scope of the whole problem)

User interface changes

this is a meta issue, no patch here to change the ui.

API changes

this is a meta issue, no patch here to change api.

Report by inspired by tsvenson and Gabor

During a Modules Unraveled podcast with plach, http://youtu.be/Z8RnEBPoqI0, about entity translation, tsvenson asked plach about revisioning and staging. plach's answer is at 27:45. tsvenson and Gabor had a follow-up discussion in irc after the podcast in which several issues were listed.

Comments

YesCT’s picture

Issue summary: View changes

Updated issue summary to move fixed issues to the issues done list

YesCT’s picture

Issue summary: View changes

Updated issue summary small white space fix.

YesCT’s picture

Issue summary: View changes

Updated issue summary make it easier for people to pick an issue by adding the sub issues.

tsvenson’s picture

Thanks for creating this meta issue Cathy as it is a great place to discuss and better understand the workflow needs for content. I'm going to write up a number of typical use cases for this over the weekend and post it here.

I agree that most of the workflow stuff will be handled in contrib, but that we need a greater understanding of the needs to be able to add support for that in core. Editorial management of translations might at a first glance seem pretty easy and straightforward, but in reality it is very complex and particularly the workflow functionality needs are many.

I think its important that the content creation workflow and the translation workflows are in principal the same, but with some important differences such as:

  • Not all the content on for example a node need translations.
  • Users might be able to only translate existing content, not create new.

However, to complicate stuff, take a product page as an example. While the product name is often the same, not translated, for most languages there are exceptions. The name might be trademarked by someone else in a country and thus will have a different name there. Then you have languages that doesn't use the same alphabet such as the Latin compare to the Chinese.

While the use of different alphabets mean that all product names will have to be rewritten, the trademark example above is much more complicated. This because it is for an individual product (node) and specific country. So, question is how to handle that?!

So, what's needed here is:

  • Be able to configure the translatability on a per language basis.
  • Be possible to override those settings on a per node basis.

This also requires two separate UIs too. The per language is done in the backend by the sitebuilder in the entity configuration, while the override is done by editorial users in the frontend. The override also needs its on permission setting so its only available for certain users.

The trickiest problem though is how to handle the trademark example above as it is really a territorial issue and not a language.

How flexible will the language support be in D8? Will it be possible to have versions in for example British English, Australian English and US English?

tsvenson’s picture

Oh, then going back to our IRC conversation earlier, work is in progress to use State Machine in Workbench Moderation.

While I haven't tested in myself, I have spoken to several of the involved Palantir developers and they said that State Machine will allow for highly flexible workflows compared to the simple Draft, Review and Publish it currently has.

YesCT’s picture

I'm not sure that the point

Not all the content on for example a node need translations.

is relevant to to translation editorial workflow. I think it might just relate to translation. Perhaps the following questions help show my confusion regarding where to draw the line.

Does this fit in here?
#1807776: Support both simple and editorial workflows for translating entities

ET ui follow-up meta
#1836086: [meta] Entity Translation UI improvements
has items like: #1832836: Discuss how to view original translation from translation form
I'm not sure where to draw the line on what is part of the translation meta and what is part of the editorial workflow meta. Maybe hand pick out some of them? Or just simply list 1836086 and it's sub issues as related, but not really part of providing support for translation editorial workflow.

YesCT’s picture

Issue summary: View changes

Updated issue summary take out repeat.

tsvenson’s picture

I'm afraid my knowledge of the internals of Drupal is too limited to judge exactly where it belongs.

In general it is a field level access case for the entity, but the example where the individual content item requires an override making it possible to just translate that particular title needs to be handled in the editorial workflow.

Then you also have the case where the two languages uses different alphabets. Then all the text content field will have to be translatable in practically all cases. But that is most likely managed from the entity editing UI. That is, if D8 allow that kind of language control.

Unfortunately I had no time during Saturday to get to start writing up those use cases I promised as something important came up. I hope to be able to get started on it Sunday though. Those use cases should allow us to work backwards and better understand what is needed in core for contrib to then be able to build it.

tsvenson’s picture

Hi Guys,

Sorry for the delay on delivering the writeups, but I have some big personal problems to sort out at the moment.

However, I just saw this tweet from @fago:

today santa brought the long overdue 1.0 release of the entity API module - with full revision support :-) drupal.org/project/entity #drupal7

While I do understand that http://drupal.org/project/entity_translation is probably doing something different to handle the translations, I still think it is worth mentioning here as it could help us be able to get both workflow and revisioning working for translations too.

Merry x-mas all.

tsvenson’s picture

Issue summary: View changes

Updated issue summary added support simple and editorial workflow issue to the todo meta list.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Berdir’s picture

Status: Active » Fixed

I suppose this can be closed. There are still plenty of bugs and issues between revisions and translations, but clearly this issue isn't actively used anymore.

Status: Fixed » Closed (fixed)

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