Problem/Motivation

If you enable translation of a content type by ticking the Enable translation checkbox
at admin/structure/types/manage/ the result is not reflected accurately
at admin/config/regional/content-language. In the configuration interface
there is a checkbox for each field in the content type. Marking the checkbox for
the content type selects all of the reasonable fields and enables the language s
elector. However if translation was enabled through the structure interface only
the main checkbox for the content type will be selected and an error will result
if you try to save the page.

  1. Set up a clean D8 site.
  2. Enable translation:
    • Enable the Language and Content Translation modules.
    • Configure a second language.
  3. Using the admin/structure interface enable translation of a content type.
  4. Create an instance of that content type.
  5. View the admin/config interface – note that only the checkbox by the content
    type name checkbox is selected (this is the first problem).
  6. Save the form. Note that you will get an error message and your changes seem
    like they were not saved.
  7. Back out of the form (go to another page on the site).
  8. Go to the translatable content. Attempt to translate the content. You may see
    errors.

Proposed resolution

Either 1) match the behaviors by making the structure interface mimic the behavior of
configuration interface, or 2) eliminate the translation option in the structure interface –
possibly with a message or link to the configuration interface.

Remaining tasks

I don't know how to reproduce this consistently, but it seems like there are potential problems
if you try to save translations options through the configuration interface that were initially set
up through the structure interface. You will get an error because there will be no selected fields
on the content type. If you don't resolve this (e.g., if you don't know what you should do and
try to leave the page) translation seems to be broken.

User interface changes

If option 1 is selected, there would be no (undesirable) user visible change. If option 2
is selected the change would be to redirect the user to the configuration interface.

API changes

I don't think there would be any.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dlu’s picture

Issue tags: +i18n
dlu’s picture

Screen shot of one of the errors encountered after backing out of an error in the configuration interface.

omar’s picture

TL;DR I've just spent quite a bit of time testing this (beta10) and have isolated the issue. Essentially, everything works as expected *except when saving the admin/config/regional/content-language form*, in which case it unexpectedly disables translation for *all the fields of all content types for which content translation is currently disabled*.

While this may sound reasonable, in fact, it leads to inconsistent behaviour and, IMO, we shouldn't be saving these values (at least not without warning the user... and even then). IMO, the solution is simply to *not set* the "translatability" status for the fields that have not been presented to the user (i.e. for content types where translation is not currently enabled).

----

Out of the box, after enabling translation for one (or all) content type(s) via admin/structure/types/manage/[content-type], most of the fields will be listed as translatable on admin/config/regional/content-language. This is a reasonable default.

Disabling translation for a content type via admin/structure/types/manage/[content-type] results in the content type being "unchecked" on the admin/config/regional/content-language page and its fields are no longer listed. So far, so good. Works as expected.

Re-enabling translation for that content type via admin/structure/types/manage/[content-type] results in the content type being "checked" again on the admin/config/regional/content-language page and once again the afore mentioned fields are re-listed as translatable. Still works as expected. Of course, why would the list of fields have changed in the meantime, right?

Unfortunately, if before re-enabling translation for the content type, you visit/save the admin/config/regional/content-language form (e.g. because you where tweaking the field selection for a content type with translation enabled), then all the fields of all the content types for which content translation is currently disabled will be set to non-translatable. Not good.

In effect, if you enable translation for content types before ever visiting/saving that content-language form, it'll list all the fields as translatable. But if you were to visit and save that form in its default/empty state *prior* to enabling content translation for the content types (when the fields aren't even listed), none of the fields will be translatable when you enable translation for the content types via the structure page. You just submitted a form in its default/empty state, but a whole lot just changed behind the scenes. :-(

All this to say that, IMO, the fix is rather straight forward; we shouldn't be saving/setting values for the fields of the content types with translation disabled.

omar’s picture

Component: language system » content_translation.module

The behaviour discussed above stems from content_translation.admin.inc so moving ticket.

omar’s picture

Hmm... then again, perhaps my assumptions were misplaced. The code is pretty clearly oriented towards fields inheriting their translation status from the bundle so the notion of just leaving the values unchanged is presumably not an option. Doh!

UPDATE: There is some inconsistent messaging... in one place we see "If an entity type is not translatable all its bundles and fields *must* be marked as non-translatable" whereas in another place we see "If we have column settings and no column is translatable, *no point* in making the field translatable."

I'll stick with my original judgement that we should not be altering the value for the fields not shown to the user.

nachosalvador’s picture

unstatu and I are working on it in the DrupalConEur mentored sprint.

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.

pameeela’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative
FileSize
58.44 KB

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging Drupal core issues with the priority 'Major'.

I've tried to reproduce this on a fresh install of 9.0.2 and I'm unable. When I enable translation via admin/structure/types/manage/article, and then visit admin/config/regional/content-language, I'm not seeing the same behaviour of "only the checkbox by the content type name checkbox is selected". When I go to this page, the content type and all of the fields (minus file field) are checked:

From there I can save the form without any issues, so I'm going to close this. I suspect this was fixed somewhere else, but I wasn't able to find the issue where this was resolved.