Steps to reproduce;

1. Enable Content Translation module
2. Add 1 language
3. Make default content type Article that comes with core translatable
4. Check that the default image field is now set to translatable ("Users may translate this field"): File is not translatable, but the Alt and Title elements are translatable (default configurations)
5. Add a node (without touching the image field)
6. Add a translation of the node and upload a image
7. Check back on the other language version; The image is not there!

If you add the image once you create the node it will be displayed across all translations. However if you later edit the image field (both in the source language or in translations) the image will only be changed in that language version (and the old image will remain in the other language version).

However it seems like this behavior is only present when making the default content type Article that is shipped with core, translatable, and using the default image filed that is also shipped with core. If you use the default image field in another content type, or create a new translatable image field to be used in default content type Article, there seems to not be any problems.

To me the issue seems a little critical though, as many people potentially will use exactly those default configurations that are shipped with core.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matsbla created an issue. See original summary.

swentel’s picture

It's weird that the behavior is not there on another content type. Other than that, the behavior seems to be design (in a way) but I agree it's a bit confusing. Doesn't sound critical though for that, because there's no data loss, rather major.

matsbla’s picture

I don't hope this is by design, wouldn't be a very good design if you ask me :)

I tried to make users profile translatable, and the same happens with the users profile images. However if a remove the default image field and initiate it again, the problem is gone. Maybe the problem is with any image field that is shipped with core?

cilefen’s picture

Priority: Normal » Major

Actually I can go with major if this is a bug.

swentel’s picture

@matsbla interesting - could you paste the configuration of a new image field (and paste the core version too if you can). I think the part where it goes wrong is not necessarily the field itself, but how the UI of content translation saves the values in the field third party settings (or maybe even in language_content_settings, although I doubt that one)

I don't hope this is by design

You're right, I misread a part of whats in the summary. There's confusion in my head, but also in the code obviously :)

matsbla’s picture

I've uploaded 2 different config files. One with image filed shipped with core and another after I've deleted and then added same image field shipped with core to article content type.

Here is the diff ('active' is core image filed after set to translatable and 'stage' is after deleting and initiating the image field again);
Diff between image field shipped with core and after it is initiated again after install

matsbla’s picture

Title: Image field that follow core gets broken when it is set to translatable for Article content type » Image fields that follow core gets broken when set to translatable

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

xjm’s picture

Status: Active » Closed (duplicate)