Problem/Motivation
The Content Translation module offers two ways to handle multilingual entities:
- Editors, that is users with edit permissions over the entity, will be offered the regular entity form, where untranslatable fields are highlighted regardless of the language being edited (see also #2290101: UI telling you a field is shared across languages is way too subtle). This mode retains the ability to perform contextual editing: regardless of language, the editor can edit all the fields that are displayed in the entity page.
- Translators, users with translation permissions but not edit permissions over the entity, will be offered translation forms, that is stripped-down entity forms with no widgets for untranslatable fields and other monolingual form elements. In this case contextual editing does not matter because translators need to always visit the translation overview page and only then they can access a translation form.
However, for editors the following behaviour is possible:
- Edit a German translation, including a change to an non-translated entity reference creating a new default revision.
- Revert that revision, the translated fields will revert, but the entity reference will not.
Even if we changed the behaviour in #2 to include the non-translated entity reference in the fields to revert, it's not clear if that would be correct either - the person doing the revert can't necessarily tell that the translator changed the untranslated field when they made the new revision.
This is just an example of a deeper issue: when saving a new revision having changes to untranslatable fields, all available languages are marked as affected, since there is no way to tell whether the user meant to apply the change only to a particular translation.
This is problematic for pending revisions on multilingual entities because, as pointed out in #2766957-73: Forward revisions + translation UI can result in forked draft revisions, a pending revisions should have only one affected language to be handled properly and be safely merged with the default revision when "publishing" it.
Proposed resolution
Add an option to choose between the two following behaviors: a change to an untranslatable field either affects all translations or the default translation only.
The first mode is the default core behavior, that suits well for simple workflows where revisions are not involved and contextual editing is important.
In the alternative mode, the Content Translation module will hide widgets for untranslatable fields in non-default language entity forms. In this case the edit form for non-default languages is identical to a translation form (see the attached screenshot). This may be slightly confusing, as contextual editing for untranslatable fields is no longer preserved, but more confusing issues are avoided.
An option in the CT's administrative UI is offered to toggle between the two modes per bundle.
Remaining tasks
- Fix blocking issue: #2924724: Add an API to create a new revision correctly handling multilingual pending revisions
Validate the proposed solutionWrite a patchAdd test coverage- Reviews
User interface changes
API changes
Only additions: ContentEntityInterface:: isDefaultTranslationAffectedOnly()
.
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#93 | image.png | 23.66 KB | keithdoyle9 |
#72 | et-untranslatable_fields_hide-2878556-71.patch | 48.07 KB | plach |
Comments
Comment #2
matsbla CreditAttribution: matsbla commentedComment #3
vijaycs85Currently this is represented by label (with "(all languages)" suffix). Probably we can have the fields as value (markup) by default and option to allow edit?
Comment #4
plachDiscussed this with @catch, this is a summary of what I told him:
I think the fact that @catch felt the need to open this means #2290101: UI telling you a field is shared across languages is way too subtle is still a very relevant issue.
To ensure we don't have an architectural flaw here, we quickly went over the issues linked in the IS:
I would be open to adding an option to hide untranslatable fields on non-default-language edit forms, but that wouldn’t solve those issues :)
Comment #5
plachComment #7
catchComment #8
hchonovI think that the following use case is worth mentioning and have to be considered if some behaviour will be changed, because it is currently possible and I think it should remain possible:
Comment #9
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedRe @plach in #4:
In D7, we had a "read only" field widget available to all field types in the Field extra widgets module. Quoting from the project page, its behavior was something like this:
Would this kind of widget be a possible solution for this issue?
Comment #10
catchComment #11
catchComment #12
plachI'm doing some work on this subject as part of #2860097: Ensure that content translations can be moderated independently. I will post an initial patch implementing the following (optional) behavior ASAP:
Comment #13
plachHere is a patch to add the option to choose between the two following behaviors: a change to an untranslatable field either affects all translations or the default translation only.
If the latter mode is enabled the Content Translation module will hide widgets for untranslatable fields. In this case the edit form for non-default languages is identical to a translation form (see the attached screenshot).
An option in CT's administrative UI is offered to toggle between the two modes per bundle (see the attached screenshot).
Tagging for usability review. Aside from that this needs test coverage as what I implemented so far belongs in #2860097: Ensure that content translations can be moderated independently.
Comment #14
plachMore screenshots
Comment #15
plachComment #16
matsbla CreditAttribution: matsbla at Globalbility commentedI made a quick check, this is a nice feature!
Just 2 comments;
maybe the check box also should be available under the language setting for each content type?
And also I tried with a translatable image field having an untranslatable image file, however I'm then still able to edit the image file on the translation form.
Comment #17
plach@matsbla:
Good points!
Ideally yes, however I'd like to avoid adding too many changes here and I'm slightly concerned by the need to always replicate UI items on the content type configuration pages. What about opening a new issue to find a standardized way to reuse these UI components both in the Language/Content Translation settings and in the Content types configuration pages?
Mmh, this is tricky to address because synchronization implies a translatable field. We should come up with some custom logic to deal with this. I'll mull on it a bit more. Maybe a follow-up would make sense here too?
Comment #18
plachTo provide proper test coverage, this now relies on the kernel test introduced in #2924724: Add an API to create a new revision correctly handling multilingual pending revisions. The attached patch adds test coverage for the API bits. We still need test coverage for the Content Translation bits. We also need feedback about #17.
Comment #19
plachWorking on the additional test coverage.
Comment #20
plachHere's the additional test coverage. Attaching the combined patch and the one to review.
Comment #21
plachCorrect interdiff
Comment #22
plachComment #23
Gábor Hojtsy@plach asked to review. This is a bit of a usability review (but not a complete one) and a bit of a code review (but absolutely not a complete one).
Is this true? The issues proposes that they only be editable in default TRANSLATIONS (AKA original language) not default REVISIONS?
Existing config structure is not extendable to store this? It looks odd to introduce yet another config place to store this. It makes shipping settings harder for example in modules/distros if this file is global site-wide.
Is this called a shared field elsewhere on the UI? I would drop the explanation. I jump first on saying "This will" is unnecessary but on second look the whole description is superfluous.
Comment #24
Gábor HojtsyAlso the title says its postponed but not explained on what...
Comment #25
hchonovI've just talked with @plach about this issue and I think that it would be nice if we show a notice on the "field add form" for untranslatable fields e.g. "If you define the field to be non-translatable then it can be only edited on the entity default translation, because the entity is configured this way.".
Comment #26
hass CreditAttribution: hass commentedI‘m wondering how this should work.
In a normal website every language has it‘s own edit permission. Not every translator should be able to edit every language because of language skills.
In such a case a user may has no permission on the default language.
Comment #27
plachAnd for the same reasons in the scenario you are describing translators should not be able to edit untranslatable fields. In fact Content Translation is already exposing translation forms allowing to edit only translatable fields for users having translation permissions but not edit permissions over the entity.
Comment #28
Gábor HojtsyWe reviewed this UI proposal on the UX meeting today. Short summary: hiding the fields looks sensible. There should be some indication though that the message was hidden. As per @yoroy that would be an informational AKA blue message. We did not discuss but there is also #23/3 that I still stand by.
Comment #29
plach@catch, @effulgentsia, @larowlan, @xjm and I discussed this issue today. We agreed to downgrade it to major as this is enabling great progress, but there is no critical functionality strictly blocked on this.
Comment #30
plachUpdated the IS.
Comment #31
plachComment #32
plachMinor clean-up
Comment #33
plach#2924724: Add an API to create a new revision correctly handling multilingual pending revisions now depends on #2926483: Add API methods for determining whether an entity object is the latest (translation-affecting) revision.
Rerolled everything after the latest changes. I'll address Gabor's review ASAP.
Comment #34
hass CreditAttribution: hass commented@plach:
I‘m confused. If an images field is not transatable what makes often sense every translator need to be able to add additional images. But with this logic this becomes impossible. Should I always ask a different translator to add an image for me? I think not.
Comment #35
plachUpdated IS
Comment #36
plachComment #37
plachThis should implement Gabor's suggestions. The only problem I encountered is that we don't have an "info" message type, so for now I set it as a warning.
Comment #38
plachComment #39
plachHere's an updated screenshot
Comment #40
plachOne more screenshot
Comment #41
plachFixed change detection logic for untranslatable fields in pending revisions. I think this should be ready for review now.
Comment #42
Gábor HojtsyJust a quick review of the UI update since I don't think I am qualified to review the deeper logic:
I would shorten this to.:
Fields that apply to all languages are hidden to avoid conflicting changes. Edit them on the original language form.
("All fields" gets confusing with "all languages" + "You can" is superfluous while "edit is the action and should be part of the link because it leads to editing).
Comment #43
plachAddressed #42 and rerolled after #2926483: Add API methods for determining whether an entity object is the latest (translation-affecting) revision was committed.
Comment #44
plachUpdated screenshot.
Comment #46
gabesulliceThis review is purely for code. I haven't looked at the UI.
We also check
Good method naming :)
This is an excellent comment.
s/either//g
s/fields/field/g
Another excellent comment.
s/fields/field/g
The entity type manager can be injected by implementing the
Drupal\Core\DependencyInjection\ContainerInjectionInterface
.See ValidReferenceConstraintValidator for an example.
I'm not sure if this needs an update hook or not, but raising it as a concern to be double-checked.
Do we need an
isset
check here too?Let's name this
$content_translation_manager
Same thing.
Same concern about this not being set.
Would
Drupal\Core\Entity
be a better namespace for this?If not, can we name this
BundleTranslationSettingsInterface
? Same for the methods.Missing variable name.
The messenger isn't in the container??
"Field that are not involved in translation changes checks should not be affected by this logic (the "revision_log" field, for instance)."
$untranslatable_field_definitions
Good message :)
Should we
s/@url/:url/g
?Ah, I see. This should definitely be
BundleTranslationSettingsInterface
.Same for these methods.
Wow... this was obviously took a tremendous amount of effort and intricacy. Fantastic job. 👏
Comment #47
xjmCan we update this issue with a more specific title? It's very easy to get confused about which issue is which in this series.
Comment #48
plachComment #49
plachWow, this was a big one, thanks! :)
1: Fixed
4: Fixed
5: Fixed
7: Fixed
8: Fixed
9: I'm not 100% sure, but I think we should be fine, since we default to FALSE and missing configuration values are interpreted as FALSE.
10/13:
empty($a['k'])
is equivalent to!isset($a['k']) || !$a['k']
, in fact "empty() does not generate a warning if the variable does not exist." (php.net).11: Fixed
12: Fixed
14: I don't think so, this is a CT-specific interface. Actually the only reason it exists is to preserve BC, since adding methods to
ContentTranslationManagerInterface
would be a BC break, give it has no corresponding base class.15/21/22: This interface lives in the CT namespace, I think adding a translation prefix would be redundant.
16: Fixed
17: Nope, see https://api.drupal.org/api/drupal/core%21lib%21Drupal.php/function/Drupa...
18: Fixed
19: Those are not untranslatable field definitions, those are all the definitions being processed. Untranslatable fields are identified in the loop body.
20: Good catch!
Comment #50
gabesulliceCool.
Mind blown. How have I not known this for so long?! Thanks ;)
Not a blocker for me, so I'll leave it up to you. I made my suggestion because all of these already exist:
s/Field/Fields/g. I'm sorry that was my mistake.
That's a confusing set of issues and change record... but there is a service. I checked with the authors of those patches and they recommended
$container->get('messenger');
and pointed me to #2924538: [META] Remove all usages of drupal_set_message and drupal_get_messages where you can see where that exact pattern is used.That was a huge initial review, so thanks for bearing with me :)
Comment #51
plach3: Fair enough, fixed
4: Fixed
5: I totally missed that, thanks! Fixed
Comment #52
plachForgot the interdiff
Comment #53
plachComment #54
gabesulliceAwesome work!
Comment #55
plachThanks, let's wait for the dependency to be committed :)
Comment #56
plachRerolled after #2924724: Add an API to create a new revision correctly handling multilingual pending revisions was committed.
Comment #57
plachComment #58
plachMinor interface clean-up.
Comment #59
gabesulliceGood catch.
Comment #61
catchLooks pretty good, a few minor questions:
This could possibly use some more explanation as to why we're mocking $entity->original.
Isn't this ternary more lines than an if/else would be?
How much of this is because we want to make this behaviour configurable, vs making it configurable to provide continuity for existing sites?
Comment #62
effulgentsia CreditAttribution: effulgentsia at Acquia commentedFrom the issue summary:
So I think it makes sense to allow for the first mode on sites that don't have pending revisions.
However, rather than making it configuration, I wonder if we should make content_moderation force the second mode (hide untranslatable fields from entity edit forms of non-default translations). Via an API that contrib modules that allow for pending revisions other than Content Moderation could also invoke.
Comment #63
plachSince the new mode can be useful also to sites using only default revisions that are experiencing troubles with reverts, I think an explicit option would ensure more flexibility. Additionally there's a similar option in Entity Translation, so people upgrading from D7 will likely be already familiar with that.
Comment #64
plachThis should address #61.
Comment #66
plachBot fluke
Comment #67
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI discussed #63 with @plach, and he convinced me that the answer to #61.3 is that it does make sense as something that's independently configurable on its own merits, not merely for continuity of existing sites. I'll try to write up why later today, to see if I understand the reasoning correctly.
Comment #68
plachComment #69
plachAdded two CRs for this and updated a related one:
Comment #70
Gábor HojtsyComment #71
Gábor Hojtsy@plach: let's not self-RTBC your updates after reviews. I reviewed the update you posted and it looked fine.
This has been reviewed by the UX team on the regular UX meetings, discussed with subsystem maintainers, reviewed by various core committers. As for the latest question that got settled, I agree having a setting is best for backwards compatibility and for other translation scenarios. It makes our translation experience more flexible. It does require sites to set this up explicitly the way they need to. I think we may be able to improve on that in the future while keeping the flexible configurability.
There are two minor code style problems found while commit:
Comment #72
plachAddressed #71.
Comment #73
Gábor HojtsyLooks good thanks!
Comment #76
Gábor HojtsyThanks for fixing these last issues so fast. Committed 27c3b40 and pushed to 8.6.x, cherry-picked to 8.5.x.
Comment #77
Gábor HojtsyPublished the two change record drafts.
Comment #78
hass CreditAttribution: hass commentedI‘m need to say I not a fan of hiding a field. Disablng is much better! Otherwise I will get asked where the field is if soneone believe he need to change it. Showing disabled will at least show it and a description can tell the user why it is locked. That is much better UX.
Comment #79
effulgentsia CreditAttribution: effulgentsia at Acquia commented@hass: can you open a followup issue for that?
Comment #80
Wim LeersThis was committed without @effulgentsia's write-up mentioned in #67.
Comment #81
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThat's ok. No need to hold up progress on my account. I'll still write up that comment when I have a chance.
Comment #82
Gábor Hojtsy@hass we added this message with that thinking as per the issue summary:
There are two problems at least with hidden fields:
Comment #83
hass CreditAttribution: hass commentedThis are already UX problems for people without vision problems... it cannot become better for people with vision problems than :-). Every few weeks I already have this type of discussions in D7 just because something is temporary hidden and they do not know why or it shows as admin, but not for non-admins. I think we just need to put a strong red note that this need to edited at foo. Something people with vision problems can also read and they do not get frustrated. Hopefully.
Comment #84
hchonovSo it looks like we have one more place where forward revisions behavior defined by content moderation has made it's way into core. So now if I've enabled the setting "untranslatable_fields_hide" I'll get the content moderation behavior regarding forward revisions even if the content moderation module isn't enabled? If this is the case then the change in
content_translation_entity_type_alter()
should be reverted.Comment #85
effulgentsia CreditAttribution: effulgentsia at Acquia commented@hchonov: I really appreciate you looking at this problem space from the perspective of potential alternate (non-CM) use cases of pending revisions. I haven't caught up with the discussion in #2940575: Document the scope and purpose of pending revisions yet, but look forward to doing so soon.
What's the Content Moderation behavior that you'll be getting? AFAICT, all you'll get is the ability to make changes to untranslatable fields when editing the entity in its default language, regardless of whether it's in a pending revision or not. But you'll get a validation error if you try to make those edits in the non-default language (which seems fairly consistent with the fact that those fields are hidden from the form anyway). What part of the hunks in #84 is incompatible with or not desirable for non-CM uses of pending revisions?
Comment #86
hchonov@effulgentsia, I am sorry if there is something I am not understanding correctly, but to me it looks like the new constraint prevents the saving of forward revisions with multiple translations and changes in non-translatable fields. This is the CM behavior, which now gets automatically activated if the setting "untranslatable_fields_hide" is enabled. By looking at the name of the setting -
'Hide non translatable fields on translation forms'
- I would simply expect that all this setting causes is that non-translatable fields are removed from translation forms and nothing else, but it additionally activates the CM behavior/constraint regarding forward revisions and prevents editing non-translatable fields in forward revisions with multiple translations.P.S. by further looking at the constraint validator it looks like it prevents the editing of untranslatable fields in multilingual forward revisions even if the setting is not enabled. I haven't noticed the else branch until now. This is CM behavior only as well.
Comment #87
plachThis is not the CM behavior, this new validator was introduced to complement the new API we introduced in #2924724: Add an API to create a new revision correctly handling multilingual pending revisions. As we discussed at length, we want to avoid data integrity issues by encouraging people to change one single translation at a time in pending revisions. This is the only approach that allows to work independently on multiple translations (and merge the result into default revisions), without needing to rely on a conflict management solution. This is especially tricky when untranslatable fields come into play, because you may end up performing this kind of problematic changes without even realizing it. Hence we decided to introduce this validator to avoid that.
Again, this logic is exploited by Content Moderation (because that's the new suggested approach), but it's not "the CM behavior" because every module out there, regardless of its interpretation of pending/forward revisions, is encouraged to adopt this logic. Of course there can be cases where you may want to implement a custom merging logic and whatnot but it's unfair to say this is CM-specific. In fact every bit of this logic lives in the core entity system.
Comment #88
hchonovWhat exactly is the problem of using conflict management? If a user is able to further edit the default and forward revisions sooner or later there will be conflicts even in translatable fields and conflict management is necessary. Having a special behavior for forward revisions is exactly what CM needs and therefore that is the CM behavior or there is another use case which needs exactly the same behavior?
Yes and I've mentioned it already at couple of issues that this is not good, because CM and CM only is needing this API restrictions, which forces the CM behavior to be the default core one.
Every module out there is forced and not encouraged. This makes a big difference.
So think about it if there is a use case like autosave using forward revisions and after the update to Drupal 8.5.0 suddenly there will be validation errors, because we suddenly force everybody to use forward revisions just like CM needs it. Therefore I would say that this change breaks BC.
Comment #89
plach@hchonov:
There is nothing wrong with that. As I told you a couple of times, I think it's great and that it should be in core. But it's not, so we cannot 100% rely on it. This is why we need an alternative way to prevent the contrib/custom space from shooting themselves in the foot. If they are wearing bulletproof boots, fine, they just need to remove the validator. Once conflict management is core I'm happy to get rid of that logic, at least when conflict management is enabled.
Yep, but there is nothing in core that allows you to edit multiple translations in the same pending revision, so you need some explicit code to do that. OTOH untranslatable fields let you do it without even realizing it.
Say you have an autosave module relying on pending revisions and you have no conflict management solution enabled. You edit an article and then pause working. While you are away, someone else starts editing the same article, but in another language, changes also an untranslatable field, and saves a new default revision. Now you get back to your desk, recover your work, and save a new default revision. You've just overridden part of the other person's work without even knowing it, since you reverted the untranslatable field to its previous value.
You have no data to support this claim, so far you only provided a couple of examples that do not need those restrictions, and they both (at least implicitly) rely on conflict management, so they need to address the same issues the validator addresses. For this statement to be true, you'd have to demonstrate that every possible use case out there does not need to rely on such a behavior, which is not true even for your own examples.
I have been saying how it's bad that we allow to change multiple translations in the same revision (even a default one) way before CM was even a thing, so I simply reject this statement.
We are enforcing a default behavior that most people actively involved in this area deem sensible, which is what usually core does. There's nothing stopping the contrib/custom space from disabling this logic with a one line change in an alter hook.
I'd argue that at the moment two ways exist to address the data integrity issues being solved here: the validator introduced here and conflict management. If the latter takes care of unsetting the validator when it is enabled, then no other module in the contrib/custom space needs to worry about these problems: they either go the core way or they install conflict management.
Sure. Also a bug fix breaks BC if you were relying on the buggy behavior and yet we fix bugs all the time. Not every behavior change can be considered a break of our BC policy, especially in an area that was clearly not mature enough in core, before the Workflow Initiative started improving it. Our BC policy concerns very specific items, for everything else it states that we will "take reasonable efforts to not break code that developers may be relying on". We don't guarantee you will never have to touch your code between minors, and for a good reason, if you ask me. Sometimes a small change now is preferable over having to deal with very serious issues later, because the root issue was not addressed strictly enough initially.
Comment #90
hchonovThis is not what I've meant. I've meant, that you create a draft and allow the users to edit drafts and default revisions at the same time in the same language which at the end results into a conflicts even for translatable fields. This is completely the same as if having conflicts in non-translatable fields. If content moderation doesn't currently support this and doesn't want to support this then this is no reason for it to require those significant changes, which prevent contrib from providing such a solution and yes the changes here forbid this.
No, this is not correct. You will not override anything as without conflict management you'll not be able to save.
Let me ask it the other way around - could you demonstrate that every possible use case out there does need to rely on the CM behaivor? What makes you think it is not true for my own examples? I've given you an example for CM which requires conflict management as well and this is the use case where a translatable field is edited in both the default revision and in the draft one after the draft has been created.
Are those people the people working on content moderation, or are there others involved, who also work on other projects making use of forward revisions?
There is nothing stopping content moderation to enforce this behavior only for the entity types it supports instead of making this a default behavior and having to discuss about this.
If we don't have to break BC and have other ways of solving bugs, then we don't break BC. The issue here could have been solved without breaking BC. So the question is why? Why should we break BC when we don't have to?
Actually we've opened a new issue and agreed to decide how we want to handle forward revisions in core #2940575: Document the scope and purpose of pending revisions and the change here should be made public, if we decide to, only after the other issue is closed.
Additionally there are use cases like with the content translation outdated flag which by editing a single translation results into updating fields of the other translations as well. If I create a draft, change a non-translatable field and select the "outdated" flag to mark all other translations as outdated, then I'll have to remove all other translations in order to save and because of this later I'll have to somehow make the changes that would've been done by the form and entity API automatically. I prefer to rely on conflict management instead of having to figure out how to deal with the problems I will have to face if I remove translations and later add them again.
If I have installed the conflict module, then core will still not allow me to save multilingual forward revisions with changes in non-translatable fields, because of the constraint introduced here.
One important question - let's assume I've removed all other translations of a forward revision just to be able to create a forward revision with changes in a non-translatable field, then I've edited the non-translatable field in the default revision, and later I want to make the forward revision the default one. How do I solve the conflict now? Because even if there is only one translation in the forward revision I am still able of creating conflicts in this field. So how do these changes here help me?
Comment #92
Martijn de WitComment #93
keithdoyle9 CreditAttribution: keithdoyle9 commentedWe just updated to 8.5 and are getting this error when trying to update an entity that has a entity reference field to a taxonomy (list of terms). We're using Workbench Moderation and after saving a draft, the users are unable to publish or move through the workflow. Is there something we're missing? We don't want to make the field translatable (the terms themselves are translated). The entity in question only has one translation in it's original language.
Comment #94
DuneBLsame as #93... I couldn't save a translated node... If "Hide non translatable fields on translation forms" is checked (8.5.x-dev)
I have only 4 fields that can be translated: Text (plain), image (multiple values), video embed an Text (formatted, long, with summary).
I have also to point out 2 issues:
1-I have another form display for this content type, and, in this form, all the fields are displayed... [in the translation form]
2-I have a use case in which I need to hide non translatable fields in the form, but in node_presave, I would like to update a non translatabled field. (This field is an helper field which will be used later in a view): is it ok with this constraint?
Comment #95
heddnOn non-obvious problem I'm sharing for posterity's sake. If your entity has certain fields that weren't previously marked translatable i.e.
changed
, etc. that always get modified during a translation revision save, then the validation error can be throw. Simply mark these fields as translatable and the validation error will go away.Comment #96
matsbla CreditAttribution: matsbla at Globalbility commentedIt seem like this change is not working for the comment field or the url alias field when these fields are untranslatable and the option "Hide non translatable fields on translation forms" is enabled.
Two bugs have been reported:
#3017157: "Hide non translatable fields on translation forms" option doesn't affect url alias field
#3015675: Translations of nodes with comment settings field set to non-translatable returns EntityUntranslatableFieldsConstraint
Comment #97
matsbla CreditAttribution: matsbla at Globalbility commentedI've added a follow-up issue for translatable fields with non-translatable image files #3026055: Non-translatabale image files in translatable image fields are editable when it is not allowed to be changed
Comment #98
bbombachiniI'll post here as this might help someone. If you are still having issues with this "untranslatable fields" error even when you don't have any untranslatable field on your CT but you have rabbit_hole enabled, this patch might help https://www.drupal.org/project/rabbit_hole/issues/2958457.