Currently, the extent of revision support in the module is that when I save a new revision of the base node, all translations are copied to the new revision too. When I edit a translation, or add a new translation, a new revision is not created. While it keeps track of who authored the translation, no revision history is kept for translations.

#21 et-revisions-1046282-21.patch16.28 KBplach
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es).
[ View ]


good_man’s picture

I did some work on this feature, the workflow is as follow:
- User creates source node
- Translates it
- Updates the translation and check the revision box in translation page.

What I did is to create a new revision of the source node (using _node_save_revision()) and then update the translation handler entity to point to this new revision, so when saving the translated fields, it points them to the new revision (the new $vid).

I'll extract the patch for that feature, and any better way to do that?

good_man’s picture

Status:Active» Needs review
new2.94 KB
FAILED: [[SimpleTest]]: [MySQL] Fetch test file: failed to retrieve [revision-1046282-2.patch] from [].
[ View ]
good_man’s picture

Also this patch is a proof of concept,and it hurts the abstraction of this project. I'm thinking of moving it to translation.handler interface and the implementation to translation.node.handler, thoughts?

plach’s picture

Project:Content translation» Entity Translation
Version:7.x-2.x-dev» 7.x-1.x-dev
drasgardian’s picture


fabsor’s picture

Status:Needs review» Needs work

This needs a reroll against entity translation.

miro_dietiker’s picture

While working on our content translation codesprint we ran into right this issue.
- Revisionned entities => nodes
- But no revisions for their (entity/field) translations

Also finally we realized that entity translation will result in issues when scaling up number of languages
- The whole entity gets locked even when working on a single transltion only. So no scaling on translators at the same time is possible
- The data amount explodes: All (unchanged) languages get copied for every translation update if revisioning would be active...
- The concept of separate per-language revisioning (as separate pathes of development) is completely missing

It showed up that only enabling revisions on a entity/field won't help much. Our issues cannot be solved cleanly just by adding this functionality. There's a lot more to be done. Finally we decided on some different pattern to moderate suggested new variants and we possibly won't rely on this feature.

Gábor Hojtsy’s picture

Component:Code» Base system

I've documented the current state of revisions vs. entity_translation at

In short:

- field translation revisions are saved when a new base node revision is saved, when a new translation is saved, no new revision is saved, the last one is modified
- translated properties are not revisioned at all

This figure is most relevant from there:


plach’s picture

The upcoming dev snapshot provides the ability to create a new revision from any language version of the entity. Entity translation metadata is still not revisioned, though.

bforchhammer’s picture

Note: in the latest dev version, the "revision history" vertical tab is considered a "shared field", i.e. it will be treated the same way as any other field which is shared between different translations. This means that...

  1. if a user does not have the "edit shared fields" permission, then the tab will be hidden completely, i.e. it will not be able to change revision settings or add a revision message.
  2. once #1770748: Option to display shared fields only when editing the original values is committed, it will be possible to hide all shared fields on translations; this would cause the tab to be hidden only on translation forms.
miro_dietiker’s picture

Already a few months ago, but i documented some thoughts about this topic with core relation and what limitations we're having.

Anyway, good to see some improvements here! :-)

plach’s picture

Yes, I read that article. I'll try to use it as a guideline when addressing this, altough I guess some considerations would require core changes.

stephen.colson’s picture

Seeing as the issue of revisions on translations is pretty much a blocker for many organizations (or so I would think) and we are unlikely to significantly alter D7 core now, what about an intermediate step?

I propose we extend what we have now to separately log which language a revision is targeting and either disable or intercept the revisions tab with a view and exposed filters for language.

We currently do not track quite enough information to make this happen, but I think we could make-do by adding a new table "entity_translation_revision" that would consist of (nid, vid, language). Make it a multi-column key spanning each and we have something that is easily join-able. All of the other information (date stamps, log entries, etc) are easily available in other tables now, so I don't see a big need to duplicate storage.

While this method would be slightly less elegant than having true revisions per language, it is also something that could be a realistic goal for 1.0 that addresses most of the concerns.

If this sounds reasonable, we (my company) are beginning a sprint soon that involves setting up entity translate, and we might be able to work this in and roll up a patch.

plach’s picture


I was planning something along these lines too, although I must say I didn't really wrapped my mind around this yet. Not sure about the revision tab hijacking, this may conflict with other modules adding stuff on that page. Anyway, this is a very important missing piece towards 1.0 so I'll be glad to review and provide direction for any concrete effort.

stephen.colson’s picture

Hijacking the revisions tab and displaying our own view is just one option. We could just as easily go the route of disabling that page or adding an additional permission option and check via hook_menu_link_alter. If we disabled the page we could add our own "Language Revisions" local task that has all the same information and I think we would be no worse off.

jmuzz’s picture

The article mentioned in #11 is at a different location now:

I made a separate issue for something that has been messing up some data on a site I am working on. Technically it could be a part of this issue but it's a pretty specific bug. #2189567: Problems enabling and disabling translation on a field with revisions enabled

jeremylichtman’s picture

Issue summary:View changes

Just wondering if anyone else is working on the entity translation - revisioning problem; i.e. before I invest effort in coding.

RobLoach’s picture

This is an interesting one. Entity Translation has come a long way, having it be revision-able would be quite the feat.

miro_dietiker’s picture

Content Entity translation in Drupal 8 supports revisions. With content entities, we mean all non-config entities.
It's still one revision graph only and nothing like per-language revisioning, but we revisioning in place.
To know what revisions affect what languages (and if they are limited to one), all revisions in the graph need to be compared to each other.
That's a pity and limits Drupal 8 core in its capabilities, but contrib could try add any extended tracking approach.

Thus, this issue is only about entity translation module for Drupal 7 and there is a very limited amount of people willing to work on this limited scope.

plach’s picture

Status:Needs work» Needs review
new13.63 KB
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es).
[ View ]

This patch enables translation metadata tracking per revision.

plach’s picture

new3.61 KB
new16.28 KB
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es).
[ View ]

This fixes a problem in the update function, one for non revisionable entity types and adds support for revision deletion. It should be quite ready for testing.

plach’s picture

Issue tags:+ET-WM integration

This is part of an effort to make Entity Translation and Workbench Moderation play well together.

miro_dietiker’s picture

Awesome, plach, to see progress with this!

Do you know what is the current / resulting status of Drupal 8 core regarding revision per language?

plach’s picture

Well, theoretically revision translation has been supported in D8 since at least one year, I think. There might be bugs but I think that from an architectural perspective everything should be in place.

goron’s picture

Patch in #21 seems to work well for supporting revisions! I'm using this in conjunction with the patches in #2218133: Workbench Moderation and Entity Translation integration, and at first pass the WM integration seems to be working well.

Mac_Weber’s picture

Status:Needs review» Reviewed & tested by the community

  • plach authored 1827397 on 7.x-1.x
    Issue #1046282 by plach, good_man, miro_dietiker, Gábor Hojtsy: Make the...
plach’s picture

Status:Reviewed & tested by the community» Fixed

Committed and pushed, thanks to everyone participating!

Mac_Weber’s picture

Thank you @plach. This is a great addition!

Status:Fixed» Closed (fixed)

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

matsbla’s picture

I want to upgrade to 7.x-1.0-beta4
Is the revision system in Entity translation now in align with Drupal 8? Will it be an easy upgrade later if we start to use the revision system in 7.x-1.0-beta4 now?
Thanks in advance.

plach’s picture

Well, let's say it's closer to the D8 model, although it does not map 1:1 to it, so a migration will still require some non trivial logic. However now at least there should be feature parity, more or less.

matsbla’s picture

okay thanks!
will there come later an upgrade path that will support migration of entity translation revisions from D7 or will we be on our own to find a solution for it?

plach’s picture