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.
Comment | File | Size | Author |
---|---|---|---|
#7 | View changes of field.field_.node_.article.field_image.png | 55.59 KB | matsbla |
#7 | image field shipped with core.tar_.gz | 36.81 KB | matsbla |
#7 | image field shipped with core.tar_.gz | 36.81 KB | matsbla |
Comments
Comment #2
swentel CreditAttribution: swentel at eps & kaas for MuseScore commentedIt'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.
Comment #3
cilefen CreditAttribution: cilefen commentedThis is likely not major according to the guidelines.
Comment #4
matsbla CreditAttribution: matsbla commentedI 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?
Comment #5
cilefen CreditAttribution: cilefen commentedActually I can go with major if this is a bug.
Comment #6
swentel CreditAttribution: swentel at eps & kaas for MuseScore commented@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)
You're right, I misread a part of whats in the summary. There's confusion in my head, but also in the code obviously :)
Comment #7
matsbla CreditAttribution: matsbla commentedI'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);
Comment #8
matsbla CreditAttribution: matsbla commentedComment #9
matsbla CreditAttribution: matsbla commentedComment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #12
xjmThis sounds like a duplicate of #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted which is a critical issue. Thanks for reporting the issue!