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.

Files: 
CommentFileSizeAuthor
#2 revision-1046282-2.patch2.94 KBgood_man
FAILED: [[SimpleTest]]: [MySQL] Fetch test file: failed to retrieve [revision-1046282-2.patch] from [drupal.org].
[ View ]

Comments

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?

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

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?

Project:Content translation» Entity Translation
Version:7.x-2.x-dev» 7.x-1.x-dev

subscribing

Status:Needs review» Needs work

This needs a reroll against entity translation.

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.

Component:Code» Base system

I've documented the current state of revisions vs. entity_translation at http://drupal.org/node/1498634#comment-5860226

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:

Drupal7EntityFieldPropertyTranslationThumb.png

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.

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.

Already a few months ago, but i documented some thoughts about this topic with core relation and what limitations we're having.
http://techblog.md-systems.ch/tutorial-howto/2012-06-drupal-8-multilingu...

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

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.

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.

@stephen.colson:

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.

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.

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

http://techblog.md-systems.ch/tutorial-howto/2012-06-drupal-8-multilingu...

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