integration with content translation functionality

For the translation process, that will need some investigation.

For the revision->live yes. The workflow is a real workflow an you can define the transitions eventhough there is no UI yet. Please review the content_moderation_transitions table. Should be self-explaining

For my client I need a revision module like content_moderation also to take care of translated nodes. For example, if I have a node (nid = 1) with source language English. Via translation a second node (nid = 2) is created, both nodes share the common tnid of 1 (since node 1 is the source node).
Now, if a new pending revision for node one is created there should also be another revision be created for node two to enable proper synchronisation. A change in node one (revision going into queue) shouldn't be published in node two by synchronisation (which would happen if no additional revision for node two would be created).

Regards,
Paul

Well AFAIK the only way to have a clean solution here is again revision branching. The translation of the english source of vid 12 would be a branch of of this version.

The feature is surely a special case, nevertheless something becoming more and more important.

Sin.star try to formalize the workflow a node should take in the moderation, and the translated pairs. Iam not yet not to used to translations (content translation) using i18n,so iam not sure how it works.

Actually, by using i18n modules the {node} table gets extended by a column named tnid (=translation node id). Each translation is a node by itself (due to different content in the means of letters) but they are linked to each other by tnid which is always set to the source node (regardless of what language it is set to, in dual system [English - German] the English version would be the source if it was created first, the German version would be the source if that was created first).
i18n adds MENU_LOCAL_TASK tab named "Translate" to the node's page. That way a translation (=new node) is created an automatically connected to the source node by setting tnid on both nodes.

So i18n takes care of the translations so there's no need of making one translation the branch of another. i18n even includes a module to synchronize values between translations (i.e. author, publication status) so if both translations are unpublished and you publish the German version the English one gets published, too. This behaviour is available as an option on the content type settings page.

However this synchronization gets screwed if you have different pending revisions (at least with the revisioning module it broke several things for me). Since my content types are created by custom modules I included all the sync stuff in the module, too. But this not the normal case. For standard node types (or defined by cck) it should be an option content_moderation could take into account (if module_exists('i18n') ....).

I'll take a look into that,
Paul

Well actually, this should go into a submodule. As most of the people do not need i18n (yet) we dont need to include it by default (and higher the risks of even more bugs).
Of course i see the usecase and to extract that i18n support as a submodule we might need new hooks / bridges in content_moderation, and thats where iam willing to change the core module so we can hook in properly.

I still have some detailed i18n questions:

1. Does i18n work with the revision in any way? so lets say, we enabled i18n when a node had the revision 4 (its our only node, so this node has 3 older version 1,2,3). When the new node (relation through tnid) is created, is there any linking to the revision which "has been translated"? Seems like it is ignored, so we have that bad "used nid instead of vid" problem.
   • If there is no connection beween the source-node and the tnid in terms of revisions, we should use a own "moderation" workflow for those translation. That means, setting a pending revision 4 live in the source node, does not change anything for the translated nodes. We need a ui so you can switch over to those translated nodes and then start workflows on their revisions (same as on normal nodes).
   • I guess the "translated" nodes are of the same type as the source node, so thats the point of failure in the current installation. Those translated nodes are not be abled to be published, as there are part of the moderation (which is activated for a node type)
2. Well, as there can be several translation, thats a relation table? i mean something which maps nid:tnid in a 1:n relation). So source is english, then we might have german, greek, and polish. So one nid maps on 3 tnid`s

   Conclusion:
   I would go for a submodule which provides a GUI for moderate translations of nodes the same way the source-nodes are moderated. There might also be a kind of shortcut when you set a source-node live, you get asked if you want to set all the translations live (but this should not be the default behavior).
   Gets more complicated, i agree - but thats the cleaner and more general way, or?

Hi Eugen,

I absolutely fine with a submodule as for the modules architecture.
Regarding your second question, i18n doesn't use an additional table for the connections, just the mentioned additional column "tnid" in the node table. All translations of a node (including the source node itself) have the same tnid which in turn is the nid of the source node (that way for the source node nid = tnid). The possible 1:n relation happens within the node table.

For your first question, revisions can't be translated that way, only nodes are translatable. Thus, if you have a node (1) with one old revision (vid 1), a live version (vid 2) and a pending revision (vid 3), by hitting the translate button i18n would add another node (2, vid 4) of the same type as the source node. Its fields would be prepopulated with the values of revision 2 (current live revision of node 1).
In my opinion it's not necessary to be able to translate a pending revision as for the content will have to be changed anyways (it's in another language after all) so prepopulating fields with current live version of source node is still fine.

For the change of publication status it would of course be really confusing and this status can't be synchronized since there is no linkage between the pending revisions of translated nodes (which is also not a task to be done by content_moderation). An artificial linkage could be produced if one would be able to restrict the number of pending revisions to one (which is kind of suggested in #729198: new option "overwrite existing revision" (sort of), to unclutter revisions list and reduce the revisions to the essential ones). Then there would always be only one pending revision for each translation and everything could be synchronized.
However, I recognize this would break the purpose of the module in some kind, so it may (if at all) only be an option.

As a conclusion, I totally agree with your suggestion. And yeah, it's getting complicated, but I've been working on that kind of solution for quite a while now (trying different combinations of modules).

Best,
Paul

Hmm, iam not sure iam getting it right, seems iam confused.

- Lets say we have the source node nid:1, now we enable i18n and make the node translateable.
- That means, the nid:1 node gets a unique tnid
- now new nodes for every language enabled ( for us now german, greek, polish) are created on deman, having the same tnid

So thats were iam at now - something wrong?

Now the question:
If we have translated nid:1, vid1 .. afterwards editing nid:1 and thus adding a new vid:2. Now we want to translate that one. What happens?
Are we then (Supported by the UI) editing that OLD node for e.g. german language (adding some new vid there) OR does a NEW node get created (and the old gets deleted?).

Sorry for questioning you that much, but to implement it or help with it, i need to understand the workflow and the relations.

Close, but not quite. By default all nodes have the tnid = 0. By enabling i18n for the node type of node 1 it's not yet getting another tnid. This happens only if a translation is created. Furthermore, the tnid will always be the nid of the source node. So all translations of node 1 and node 1 itself, too, will have a tnid of 1 (as soon as the first translation is created). Apart from that minor point, you're right on target.

Now for the question: So we have a node (nid 1) with two revisions (vid 1 & 2). Here my question would arise: is this second revision still pending or live already?

Without content_moderation there is no pending revision, so rev 2 would be live immediately after saving. When translating, not the revision gets actually translated but the node (nid 1). i18n creates a second node (nid 2, vid 3 will be automatically assigned to that) and both nodes get tnid = 1.

Hope, that clears it up a bit. And don't be sorry for asking, it IS a complicated matter for there are so many ways of possible behaviour.

Best,
Paul

I've made a small fix that keeps the tnid links intact. Does nothing more, so it might be a bit oversimplified. But works fine for me.

@9 could you open a seperate issue for this including this patch? I would have some questions and detaisl on this to finally include the patch, but i dont want to keep the dicussions here. The topic is here is much more general and handles the "bird view" of the i18n integration.

Thank you for the contribution!!

posted the fix in #9 in a new issue: http://drupal.org/node/768758

There's been no activity on this in over a year and the version it relates to is _really_ old.

Having read through the comments I'd have to agree that this would best be served by a submodule.

Closing this unless someone has that submodule to commit against the current version of Content Moderation.

perfect