Follow up for #1807692-72: Introduce a column synchronization capability and use it to translate alt and titles through the image field widget also see (#75)
Problem/Motivation
if create a source and a translation without the sync setting. after turn on sync, they are still different (not sync'd).
Proposed resolution
Give a warning? Like: Previously translated content retains possible different values. Values will sync when the values are edited. (but with much better wording)
Remaining tasks
- check now that other issue #1807692: Introduce a column synchronization capability and use it to translate alt and titles through the image field widget done, if this is still reproducible
- (novice) make initial patch to give warning
- final wording of the warning
- (novice) document steps to test
Steps to reproduce
(these are a work in progress, update them as needed)
- get most recent drupal 8 (git pull --rebase)
- enable Content tranlation under Extend
- add a language
- configure Content Language Settings to make a content type and it's fields translatable, specifically make image file translatable in article
- create sample content in english
- add a translation (with different values in body, image file, etc)
- go back to the content language settings configuration page, and sync (uncheck translable) for the image file (could do it for body, but file is a more likely use case)
- (there is no warning. the proposal is to make a warning at this point)
- go see the english and the translation, they have different images still. even though the setting is to not translate them.
- save one, and then the other has a sync'd image
User interface changes
No ui changes.
API changes
No API changes expected.
Comment | File | Size | Author |
---|---|---|---|
#28 | 1909212-add-warning-29.patch | 2.87 KB | Anonymous (not verified) |
#27 | 1909212-add-warning-27.patch | 5.09 KB | Anonymous (not verified) |
#25 | add-warning-1909212-25.patch | 3.91 KB | Anonymous (not verified) |
#23 | 1909212-add-warning-23.patch | 1.8 KB | rbunch |
#20 | article.jpg | 141.86 KB | balagan |
Comments
Comment #0.0
YesCT CreditAttribution: YesCT commentedUpdated issue summary, added a first try at steps to reproduce
Comment #1
chrisjlee CreditAttribution: chrisjlee commentedComment #2
pixeliteI followed steps 1-7 and get to this step:
Here's what I would propose for the warning text about fields being synchronized when values are edited: Disabling translation for this field will not delete the translated values. When the field value is edited in any language, all values for the field will be automatically synchronized.
However, when I go back to look at the field (step 9), the images do seem to be already synchronized (i.e. the French translation of the field is already deleted). Has the synchronization behaviour changed?
Comment #3
chrisjlee CreditAttribution: chrisjlee commentedComment #4
Gábor HojtsyIt may very well be that this is already fixed thanks to some other rework. Needs one more person to test I think.
Comment #5
kfritscheI followed all the steps.
At Step 8 the message from #2 appears.
After confirming this dialog, all nodes are already synced. So Step 10 (save) is not needed.
But I did played a little bit around and came across some strange behaviour and have to look, if there are corresponding tickets open.
1. Even if I set Image - File as not translatable (only Titel and Alt of Image), I just could remove the Image at the translation, upload a new one and had two different images for the original and the translated node. Its seems to me, after I did this, I can't set Image to not translatable anymore. Batch job crashes, I need to investigate this further. (Could be "Drupal\Core\Entity\EntityStorageException: Missing bundle for entity type node in Drupal\Core\Entity\DatabaseStorageControllerNG->create() (Line 104 in .../core/lib/Drupal/Core/Entity/DatabaseStorageControllerNG.php).")
2. I didn't got the warning when enabling translation for one and disabling translation for another field and clicking on save in the translation settings. (/admin/config/regional/content-language)
Because of 2. I'll let this issue active, but I currently try it again on a fresh install, because of weired errors I'm getting (maybe because of 1.)
update:
1. Syncing works, if done after the initial translation. But when you create a translation you can change the image, even when image file is not translatable. Batch job to change the translatable state of images runs now for 20minutes and nothing happens, but no errors - cpu at 60%. No clue what is happening here.
2. The warning is completly not happening, when updating translatable at Content languaguage settings (/admin/config/regional/content-language)
Comment #6
mgiffordSimple change in the title.
Comment #7
YesCT CreditAttribution: YesCT commentedI found images always sync'd #1807692-131: Introduce a column synchronization capability and use it to translate alt and titles through the image field widget
I think we need an issue for that.
Comment #8
Gábor HojtsyComment #9
stefan.r CreditAttribution: stefan.r commentedComment #10
stefan.r CreditAttribution: stefan.r commentedThis will be reworked in the near future. We are planning to remove the data migration so this warning will not be meaningful any more. Refer to #2076445: Make sure language codes for original field values always match entity language regardless of field translatability for details.
Comment #11
plachWe should have a viable solution in #2076445: Make sure language codes for original field values always match entity language regardless of field translatability that will let us switch field translatability without requiring a data migration, hence this UI will just go away. Postponing for now to wait to be sure this actually is the case.
Comment #11.0
plachUpdated issue summary, fixed html ending tag for li
Comment #12
klonosComment #13
YesCT CreditAttribution: YesCT commented#1807692: Introduce a column synchronization capability and use it to translate alt and titles through the image field widget is fixed and this was postponed on that, so reactivating this.
next step is probably to see if can still reproduce this.
Comment #14
george.echim CreditAttribution: george.echim commentedI'm going to try to reproduce this.
Conclusion:
Step 8, there is no warning (warning does not work)
Step 9 english and translated version are sync'd without changing one of them (sync works)
Comment #15
sebi CreditAttribution: sebi commentedNo warning presented on step 8. (though I don't recall applying a patch to add this behavior)
During my testing I made the body field and image file field translatable. After I followed step 7 to remove sync, the following happened when editing the node:
1. The default (english) translation looked fine as expected: http://note.io/1mXbIG0
2. The spanish translation body reverted back to english.
3. The spanish translation for the file image did NOT revert back to english version as seen here: http://note.io/1mXcJxT
On another note, the site cache needed to cleared in order to see the change when viewing the node regularly.
Comment #16
naveko CreditAttribution: naveko commentedI also played around a little bit with this and found the behaviour for the image file is broken. The alt text and title work well, but if the 'File' checkbox is ticked the same image is used for the nodes in both languages. I also think it is strange to say a file is 'translatable'. I would prefer a help text saying something like 'Allow usage of different images in translations'.
Comment #17
naveko CreditAttribution: naveko commentedComment #18
naveko CreditAttribution: naveko commentedAfter a clean install and enabling the Content Translation module the 'translate' tab is visible after creating a new article, even though I hadn't enabled any settings on admin/config/regional/content-language. When I click 'translate' there is no option to add a translation. This behaviour is a bit strange, I think. It would be better not to have the 'translate' tab if no element of the content type is configured for translations.
Comment #19
naveko CreditAttribution: naveko commentedHere's a screenshot of what you see when the translatability of the content type 'article' has not been configured yet.
Comment #20
balagan CreditAttribution: balagan commentedI have also played around with it, and noticed when the translation image overwrites the other language (for York for example it was not overwriting, weird..), then listing the content on the front page all link to the translated version (in my case http://localhost/drupal8/hu/node/3). The detection settings were the default (from URL). On the image my cursor was over the title of the English article, see the url in the bottom left corner.
Comment #21
rbunch CreditAttribution: rbunch commentedWorking on reproducing with Ryan Weal (mentor) help at Drupalcon Austin.
Comment #22
rbunch CreditAttribution: rbunch commentedConfirmed issue still exists. Working on adding a warning when changing "configure Content Language Settings."
Comment #23
rbunch CreditAttribution: rbunch commentedAdded a warning message when an entity type is no longer set to translatable. It may need further work if this feature is required at the field level.
Comment #25
Anonymous (not verified) CreditAttribution: Anonymous commentedI reworked this patch sightly to make the tests pass when processing these elements.
@rbunch thanks for your contribution today. There were a few coding standards changes I made to help the patch along. In particular: no spaces at the end of lines allowed, the lines with comments must be only 80 characters wide, and when you open a { } statement you must put a space before opening it if it follows ( ). So it would be () {}.
I also removed the dynamic display of what bundles contain changes; this was to simplify the test. I'm still quite new to testing.
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commentedLooks like I should have followed the guide to creating patches.
Comment #28
Anonymous (not verified) CreditAttribution: Anonymous commentedReroll without the migrate-mysql patch I had in my rebase script. :S
Comment #31
Anonymous (not verified) CreditAttribution: Anonymous commentedAh, ok... I think I see what is going on. My testing skills are slowly getting there, but DrupalCon tiredness is catching up to me.
LanguageConfigSchema test fails because is not enabling content for translation, and this is where we had targeted our modification. It probably makes more sense to target the message in this patch for the User/Picture field as there are already tests based around this particular implementation.
Comment #32
rbunch CreditAttribution: rbunch commented@Ryan Weal, I don't follow your solution. Can you give me more detail or hit me up on IRC (rbunch)?
Comment #33
Anonymous (not verified) CreditAttribution: Anonymous commentedQuick summary:
We're testing if node types were changed from translatable to non-translatable.
We also need to test for user being set from translatable to non-translatable (default has a "picture" field).
It looks like we might not know if each field is an image field or not, so I think the node stuff is sufficient.
There are already-existing tests that confirm if we can make the user/picture field translatable and then change it back to non-translatable. So if we can check for that in the user object as well, then I think the remaining tests will pass.
Comment #34
YesCT CreditAttribution: YesCT commentedunassigning since it has been several months.