The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Steps to reproduce:
- create a new node of a type where entity_translation is used for translation and leave it as 'unpublished' (table 'node', column 'status' = 0)
- add and save a translation
- now publish the original node (table 'node', column 'status' = 1)
Result:
- the translation status of the original language version remains at 'unpublished' (table 'entity_translation', column 'status' = 0)
- the translation status of the translated language version is at 'published' (table 'entity_translation', column 'status' = 1)
- anonymous users can not see the original language version of the node
- there is no way from the interface to set the translation status to published
Expected behavior:
The translation status of the original translation should switch to 'published' when the node itself switches from unpublished to published.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | entity_translation-translation-status-1347126-18.patch | 4.34 KB | das-peter |
| #13 | entity_translation-translation-status-1347126-13.patch | 776 bytes | das-peter |
| #3 | translation-status-1347126-3.patch | 697 bytes | reglogge |
Comments
Comment #1
laur3ntlapo commentedSame issue.
Comment #2
drewmacphee commentedSame
Comment #3
reglogge commentedHere's a first patch, which is probably totally wrong - but it works...
I added a function using hook_node_update() to update the entry in the table entity_translation to mirror the translation status to the publications status of the node.
This probably needs to be expanded to cover all possible entities.
Also setting the priority to major, since there really is no way to publish a translation when the node was originally saved as unpublished. And since that seems to me to be a fairly normal workflow for editors (save a first draft without publishing, working on the content, and finally publishing it) that's a real problem.
Comment #4
reglogge commentedAnd this of course needs a test. Tagging.
Comment #5
plachI remember to have coped with this while working on the new UI. Please check the ml_edit_form branch and see if it fixes your issue.
Comment #6
plachComment #7
longwavePatch in #3 works for me, although the query should also include a condition for entity_type == 'node'.
I was testing this while the last two comments were posted, and haven't had a chance to look at the branch yet.
Comment #8
longwaveResetting issue status
Comment #9
reglogge commentedTesting with branch ml_edit_form.
- The links for adding a translation or editing the node from /node/xxx/translate are broken in that branch. They just lead to /node/xxx. So it's not possible to create translations for testing purposes.
- However, changing he status of the node from its regulare node/xxx/edit form now also changes the value of the status column in entity_translation table
So, the issue seems to be at least partly fixed in ml_edit_form, as far as can be tested without being able to create translaitons. It would be interesting to see if the status of translations also changes along with the status of the original node.
Comment #10
longwavePosting to note that this patch significantly impedes performance when importing nodes with migrate, this can be alleviated by adding
->condition('entity_type', 'node')to the query.Comment #11
reglogge commentedSetting back to needs work, since it's been established that the issue is at least partly resolved in branch 'ml_edit_form'.
@plach: Can you point me in the right direction as to what you did in that branch that resolves the issue? I would then proceed to roll a new patch against current HEAD to incorporate this and if needed also longwave's comment in #10.
Comment #12
ioannis.cherouvim commentedFor me this also affects content types with "node translation" and not only content types with "entity translation". The entity_translation.status remains 0.
Comment #13
das-peter commentedUpdated the existing patch since the question in #11 is still open.
Added the entity type condition as suggested by longwave, as this is not only performance relevant but critical. Without this conditions the status of an entity other than node but with the same id would be overwritten.
Comment #14
plach#1495648: Introduce entity language support is going to land soon. After that happens I will roll a new alpha and then commit the new UI patch. Please confirm #13 works so this can go into the alpha 2 which will be the latest release featuring the old UI. This should be already fixed in the new ml_edit_form branch.
@#13
Can't we solve this at form level instead that afer saving the node?
Comment #15
das-peter commentedThe question is if the translation status (of the original language) is really related to the entity status. The status of the other languages isn't related to the entity status.
Shall it be possible to unpublish the translatable fields (translation status) while the untranslatable fields still are published (entity status).
If so, I suggest to add a form element (
$form['translation']['status']) to configure this setting inentity_translation_form_alter()and of course all the code to handle this.Btw. related to the version switch to the new ml form branch:
Wouldn't it be better to be bold and create for this a new major version?
Comment #16
plach@das-peter:
It's not matter of boldness but time availability: it's already very difficult for me to maintain one branch of ET and work on D8 core. I simply wouldn't be able to maintain two different branches.
The core patch has landed, so expect a new alpha to be released soon and the new UI committed :)
Comment #17
das-peter commented@plach: okay I see the issue. And I just read the core ticket is fixed - congrats! *yay*
Comment #18
das-peter commentedI gave the suggested approach in #15 a shot.
Doing so I came across an possible issue in
entity_translation_edit_form_save_submit().The function reuses the translation handler from
$form['#handler'], unfortunately this handler doesn't reflect the latest state of the handler. E.g. the "correct" handler returnsTRUEfor$handler->isTranslating()the handler in the form doesn't.This leads to triggering
EntityTranslationDefaultHandler::setOriginalLanguage()every time a translation is saved.The patch also contains a possible API change since
EntityTranslationDefaultHandler::getStatusnow returns the set translation status and not the entity status. (Not sure if this deserves a new function)Would be nice if we could fix this in the old version before the new approach is merged.
Comment #19
plachI'm sorry but with this patch we would be diverging too much from the currest master branch behavior. We would risk to introduce more errors which would not be fixed in the dev release, since it will be largely different. People needing this fixed will have to use the new UI.
Comment #20
cweagansIs there any way that the patch in #13 could be reconsidered? We have been using it on a client project for some time now and it'd be very nice to get into the next alpha. I won't change the status on the issue, but I'd really appreciate it if you'd consider it :)
Comment #21
plachNope, sorry. There won't be another alpha: the current dev release will become a beta very soon: #1624830: Plan for Entity Translation 7.x-1.0 release and AFAIK this bug is fixed in the dev version. Everyone is encouraged to test the lastest dev so that unpleasant surprises won't come out when installing the beta.