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

Steps to reproduce

(these are a work in progress, update them as needed)

  1. get most recent drupal 8 (git pull --rebase)
  2. enable Content tranlation under Extend
  3. add a language
  4. configure Content Language Settings to make a content type and it's fields translatable, specifically make image file translatable in article
  5. create sample content in english
  6. add a translation (with different values in body, image file, etc)
  7. 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)
  8. (there is no warning. the proposal is to make a warning at this point)
  9. go see the english and the translation, they have different images still. even though the setting is to not translate them.
  10. save one, and then the other has a sync'd image

User interface changes

No ui changes.

API changes

No API changes expected.

CommentFileSizeAuthor
#28 1909212-add-warning-29.patch2.87 KBAnonymous (not verified)
#27 1909212-add-warning-27.patch5.09 KBAnonymous (not verified)
#25 add-warning-1909212-25.patch3.91 KBAnonymous (not verified)
#23 1909212-add-warning-23.patch1.8 KBrbunch
#20 article.jpg141.86 KBbalagan
#19 Screen Shot 2014-03-25 at 11.45.11 AM.png21.79 KBnaveko
#2 BLOTVY-2013.5.23-16.14.png104.69 KBpixelite
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Issue summary: View changes

Updated issue summary, added a first try at steps to reproduce

chrisjlee’s picture

Assigned: Unassigned » chrisjlee
pixelite’s picture

FileSize
104.69 KB

I followed steps 1-7 and get to this step:
Disabling translation for a field
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?

chrisjlee’s picture

Assigned: chrisjlee » Unassigned
Gábor Hojtsy’s picture

It may very well be that this is already fixed thanks to some other rework. Needs one more person to test I think.

kfritsche’s picture

I 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)

mgifford’s picture

Title: warn when sync enabled on field with previous values, they are not sync'd until one is changed » Warn user when sync is enabled on field with previous values, they are not sync'd until one is changed

Simple change in the title.

YesCT’s picture

Gábor Hojtsy’s picture

Component: translation_entity.module » content_translation.module
stefan.r’s picture

Assigned: Unassigned » stefan.r
stefan.r’s picture

This 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.

plach’s picture

Status: Active » Postponed

We 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.

plach’s picture

Issue summary: View changes

Updated issue summary, fixed html ending tag for li

klonos’s picture

YesCT’s picture

Assigned: stefan.r » Unassigned
Issue summary: View changes
Status: Postponed » Needs review

#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.

george.echim’s picture

I'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)

sebi’s picture

No 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.

naveko’s picture

I 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'.

naveko’s picture

Status: Needs review » Needs work
naveko’s picture

After 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.

naveko’s picture

Here's a screenshot of what you see when the translatability of the content type 'article' has not been configured yet.

balagan’s picture

FileSize
141.86 KB

I 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.

rbunch’s picture

Assigned: Unassigned » rbunch

Working on reproducing with Ryan Weal (mentor) help at Drupalcon Austin.

rbunch’s picture

Confirmed issue still exists. Working on adding a warning when changing "configure Content Language Settings."

rbunch’s picture

Assigned: rbunch » Unassigned
Status: Needs work » Needs review
FileSize
1.8 KB

Added 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.

Status: Needs review » Needs work

The last submitted patch, 23: 1909212-add-warning-23.patch, failed testing.

Anonymous’s picture

Status: Needs work » Needs review
FileSize
3.91 KB

I 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.

Status: Needs review » Needs work

The last submitted patch, 25: add-warning-1909212-25.patch, failed testing.

Anonymous’s picture

Status: Needs work » Needs review
FileSize
5.09 KB

Looks like I should have followed the guide to creating patches.

Anonymous’s picture

Reroll without the migrate-mysql patch I had in my rebase script. :S

The last submitted patch, 27: 1909212-add-warning-27.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 28: 1909212-add-warning-29.patch, failed testing.

Anonymous’s picture

Ah, 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.

rbunch’s picture

Assigned: Unassigned » rbunch

@Ryan Weal, I don't follow your solution. Can you give me more detail or hit me up on IRC (rbunch)?

Anonymous’s picture

Quick 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.

YesCT’s picture

Assigned: rbunch » Unassigned
Issue tags: -Novice, -needs initial patch

unassigning since it has been several months.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

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

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

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

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.