Subfield translation option - behave as core Drupal fields

I tested this before the release and I tested just now and I'm not able to reproduce. I marked 2 subfields as "non-translatable". Created node in english with the set values and then created a spanish version of the node where the 2 fields were hidden. I checked the database and the spanish version indeed shows the english records as the values. I'm not sure if maybe you have some different language settings or permissions or something but I don't know how to help since I can't reproduce.

You are right Andy, with a situation starting from scratch it works. Instead, I made modifications to a paragraph that contained a custom field adding another custom field, setting values to the second one, translating, then removing the previous one, etc.
In summary, I am now in the situation where editing a translation, the untraslatable subfields consistently are and remain NULL.
I don't know if I can exactly reproduce the steps that led to having null values in the untranslatable subfield of the translated custom field, sorry.
What is sure is that when a subfield is set to NULL and is not translatable, then following edits of the macro-field leave it as NULL: I think that is "normal" since the untranslatable subfields are set just in the creation of the translation and not checked/reacquired in editing, correct?

Yes, thats how core fields work. When you create a translation, the entity is cloned from the default language. I'm not sure the best way to resolve the current situation other than just unlocking the ability to edit the translated fields, setting the values and then locking back up. Paragraph entities can get really tricky with multi-lingual but as the node is cloned during translation creation, so are the paragraphs (assuming they are also marked as translatable) and their fields. Once the translation is created for the node, you're pretty much locked into it as a separate node. If this makes sense and sounds like the issue, let me know so we can close this bug as I really believe the way its coded is in line with how core fields work.

Hi, non translatable core fields actually have a different out-of-the-box behavior: they are modified in a single point/record and their value is shown in every language.
When this is applied to a custom field subfield a big issue appears: when the macro-field translation is created, the value is copied into the translation but if the value is later changed in the default language, the translation will keep showing previous value that is wrong.
For me this is a blocker issue to use this new feature of custom field.
Maybe a hook to replicate non translatable values / hidden values to all translations whenever custom field is edited in the default language can be a solution?
thanks

Okay, thanks for the additional info. Let me see what i can come up with.

I think i've got the logic worked out in a presave hook now that syncs the values. I have a question though, if a subfield is unchecked for translatable meaning the field won't be displayed in non-default languages, should we ALWAYS copy and set the value from the default language? What if the subfield was at one time checked as translatable and has an existing value, but then later you uncheck the box and its no longer translatable. When saving the default language entity, should we override the existing value when it was translatable or retain it? I'm thinking we should maybe override it always but wanted to get your thoughts.

The attached patch SHOULD work for you but answer the question above as I made the assumption in the code that we would just always set value from default language if the subfield is marked non-translatable (even if it has preexisting value). Let me know please. Thanks!

Hi, I think the presave should be applied when we are in the default language, not the opposite: untranslatable fields are edited only in default language, when the new value must be synchronized to all translations; current implementation requires the user to edit each translation to have the new values applied to the translation itself, while it should be immediately synchronized when the default language entity is edited.
About overriding, I agree with you that is better to always apply it, you might add a warning in the form that changing translatable state to NO after having inserted values will propagate the value to all versions.
cheers and Happy New Year

I think now it just behaves like core does so it can be assumed that the box being unchecked means the same as core which is values will sync from default language. In my testing, the value will sync from default entity value only when the subfield is unchecked. It will sync on default language entity save and translation entity save but the translation entity save will NEVER overwrite values on the default language entity. I could add help text to the field that explains this but core doesn't have that and I don't want to clutter up the form more if it's generally understood. Let me know if you think it is indeed necessary and can do that. Also, were you able to test the patch and verify it works as expected now?

Yes, it works!
You can avoid adding the help text, as drupal core does not say it either.
Just a question: you sync also on translation entity save otherwise hidden&translatable fields would be overriden...? Hidden&translatable fields cannot be altered in non default language form, so I was wondering why you sync them, but probably it's necessary as well :)

Just a small problem: as default, "User may translate this field" is checked for subfield, it should be unchecked.

Also: when creating a translation for the first time, translatable fields values should be filled in with the values from the default language entty (now they are empty, at least in a paragraph).

I made the subfields default checked because if the field itself is marked translatable then its assumed at least one of the subfields should be checked or else you're gonna end up with just a field label and some undesirable behavior if the field is also required. But I can reverse that default and force the administrator to make sound decisions on the settings. And yes, i think the proper behavior is to also sync on translation save to inherit default language value if a field is untranslatable. That way if you needed to do a bulk update on entities, the behavior would be consistent across all translations. I just updated patch if you want to retest. Once you let me know its good, i will merge into dev. Thanks!

have you seen also #15 🐛 Subfield translation option - behave as core Drupal fields Active ?

I havn't tested for that behavior. Do other fields work that way with paragraphs? I would think the overall field value would kick in that way but not 100% for sure I guess.

You are right: other fields have the same issue with paragraph, so it must be a paragraph issue.
For me this MR is ok!

Thanks for all the help in testing this. Please follow this other new feature that I'm working on if its of interest to you. I'll have something to test for it soon that I would appreciate your review: https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active

I think there's still an issue here that we ran into after the 3.0.3 update: we have two languages enabled, English and German. The default language is German.

Now, if an editor creates a new entity in English, the custom field, which is not translatable, does not show. This is because of this access check:

$access = $entity->language()->isDefault() || $is_translatable;

Shouldn't this take into account, that for new entities, the fields should always be visible? So, maybe as simple as this:

$access = $entity->language()->isDefault() || $is_translatable || $entity->isNew();

@jurgenhaas,

..the custom field, which is not translatable, does not show

It seems to be the correct logic as is no? If there is no default language entity and you're creating a translation in another language, why would you want to expose a form field that is NOT translatable? Would the solution not to be just make it translatable? Otherwise, as soon as you create the translation in default language, it would replace values for any other translation anyway. In this case I would think you'd also have the "hide non-translatable fields" setting checked in the content translation settings. Admittedly, I don't think I've ever understood why that setting exists in content translation settings as why would you ever expose the form field in non-default languages if the field is NOT translatable. Maybe you can help me understand what I'm missing though ;)

But if the entity doesn't get translated for a while? Then the user has no chance to fill the non-translatable values. My understanding is that the non-translatable fields should not be changed during translation. But when creating new content, the input to those fields should always be possible.

Example: you have a product with a label and a price. The label is translatable, the price is not. If that product gets originally created in the non-default language, it should still be possible to enter the price.

Splitting the noted issue out into its own ticket since this one is already merged. New ticket is: https://www.drupal.org/project/custom_field/issues/3497244 🐛 Translatable subfield access logic not using correct entity object for conditions Active