In a current project we have a node with an image field. This image field is marked as translateble because the alt field of the image should be translated. This means we've set the field to be translateable, but only checked the alt field and not the file field as translatable in the field settings.

This works fine, adding an image will add it to all translations. Replacing the image with a new one replaces it for all translations. Editing the alt text will only change the current translation. All is well.

However, deleting the image in one language will not delete it for all translations. So suddenly they are not synced anymore.

Also, if the client edits the original language that still has the image since it was not deleted, the image will turn up again in the language where it was previously deleted, since adding an image is synced across translations. This seems to me like a bug.

Steps to reproduce
1. Spin up a new Drupal 8.2.3 installation on Simplytest.me
2. Enable the content translation module and Add a new language
4. Go to /admin/config/regional/content-language
5. Check "Content" and check "Article" to enable translation for that node type. Make sure the Image field is checked as translatable but the "File" checkbox is off (it should be by default).
4. Create a new Article node and upload an image
5. Translate the article, (it will have the image populated automatically) and save the translation.
6. Edit the translation and remove the image.
7. Visit the node in the original language.

Expected result
The image is removed in the original language as well.

Actual result
The image is still there. Editing this node and saving it will recreate the image in the translated version.

Comments

reekris created an issue. See original summary.

reekris’s picture

Issue summary: View changes
reekris’s picture

Just found this issue which could be a duplicate of this one #2428129: Removing shared file from translation does not remove from other language. However it's unclear if the Image field on the article node is set as translatable or not in that issue. When an image field is not set as translatable it will be deleted in all languages, so that case seems to work as intended.

matsbla’s picture

Can it be related to this #2837023: Image fields that follow core gets broken when set to translatable

Do you get same result with image fields in other content types?

reekris’s picture

It seems to be related, although I'm having the same issue with Image fields other than the default one on Article. In a current project I have created an image field on a custom content type and also an image field in a Paragraph entity. They both exhibit the same problem.

These fields were created some time ago though, maybe something has changed in the default configuration since then that makes newly created fields work now. I will try creating a new image field and see if it works.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

pameeela’s picture