- 🇩🇪Germany D34dMan Hamburg
I see that, for such cases the ui does detect that the field item was removed.
Was wondering if it could be possible to "uncheck" the row so that it is not considered for translation. I tried adding an empty field value, but it won't allow me to submit the form :)
- Status changed to Needs work
4 months ago 2:45pm 10 January 2025 - 🇨🇭Switzerland berdir Switzerland
I don't think this approach is correct, we don't know if there are any fields that aren't handled by TMGMT and should in fact be kept, things that are manually translated. As shown in the failing test, that is, per comment there, a deliberate decision.
So I think it's unlikely that this will be committed.
Also, per 🐛 Error when creating new translation Active this seems to fail on the latest version.
- 🇺🇸United States euk
In my application I am working with two languages - EN and ES. I have node entities referencing paragraphs with fields referencing other paragraphs. The translations seems to be failing on the nested paragraphs (or maybe any embeddable entities). That is when this patch is applied. Long story short - the patch does not seem to account for nested/referenced entities such as paragraphs.
I don't know the internal mechanics of the translations that deep, so can't really tell what is happening under the hood, but the
Drupal\tmgmt_content\Plugin\tmgmt\SourceContentEntitySource::doSaveTranslations
has the following flow when it comes to translating a node with a referenced paragraph:- on the first call it deletes existing translation of the parent node entity (if the translation exists) - this is a change the patch introduced,
- then it recreates a fake translation with the original untranslated values (source language), gets the actual translation for the target language, then
- goes over parent entity's fields - sets translated values, then
- goes over embeddable fields - and attempts to set values for each embedded field's item (in my case paragraph) by recursively calling itself with the paragraph as the entity to operate on.When the initial
doSaveTranslations
call is made, the passed in node entity has the default (source) language set as the active language, and when the second recursive call is made for a referenced entity (paragraph in my case) - the passed in referenced entity has now the target language set as the active language. ThedoSaveTranslations
method once again attempts to delete existing translation for the passed in entity (paragraph this time) and then goes over the same workflow - paragraph own fields, referenced entities' fields.It fails on line 528:
527: if ($manager->isEnabled($translation->getEntityTypeId(), $translation->bundle())) { 528: $manager->getTranslationMetadata($translation)->setSource($entity->language()->getId()); 529: }
Not entirely sure what is the purpose of the line 528, but calling
setSource()
eventually leads togetTranslatedField
, where there the following unexpected condition happens:protected function getTranslatedField($name, $langcode) { if ($this->translations[$this->activeLangcode]['status'] == static::TRANSLATION_REMOVED) { throw new \InvalidArgumentException("The entity object refers to a removed translation ({$this->activeLangcode}) and cannot be manipulated."); }
$this->translations[$this->activeLangcode]['status']
is actually NULL, but the "==" makes it equal tostatic::TRANSLATION_REMOVED
which is 0. Changing the operator to "===" solves the issue for me.This however does not address the origin of the issue, which I believe is the way nested paragraphs are being processed after the patch is applied - the source should not be set to the target language on the line 528.
- 🇺🇸United States euk
Performed more testing and troubleshooting - no luck. Then looked at the dates - it has been almost 3 years since the patch was added. Back then TMGMT was v1.0. I removed the patch and everything worked as expected. The issue described in this ticket seems to be gone, which means the patch is no longer needed. Removing patch also fixes 🐛 Error when creating new translation Active
This needs review and testing.