Translatable subfield access logic not using correct entity object for conditions

Please test patch.

This is looking pretty good, but there is 1 part that I found that still needs a change.

Checking for $entity instanceof TranslatableInterface isn't what you expect. This is because all content entities are an instance of ContentEntityInterface which extends TranslatableRevisionableInterface which extends TranslatableInterface. In other words: every content entity is an instance of TranslatableInterface.

What you really want to check is $entity->isTranslatable(). This gives you the real information whether the current entity is translatable. If it's not, you can skip all the translation logic.

It seems that this is not only within the scope of the current MR. You most likely need to replace $entity instanceof TranslatableInterface with $entity->isTranslatable() in the whole code base.

Thanks for catching that. I've made revisions and ready to review again. Noted other places in the codebase will need similar revisions and those places should be limited to the formatter logic which I'm in the process of refactoring/simplifying logic as part of https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active . Mainly the BaseFormatter.php file handles some logic for entity references so I will take care of it there in that ticket so we can keep the scope of this ticket limited.

This is looking good for the use cases I've tested before and again after the last commit. Not sure, if this now covers everything, though. It's certainly a complex topic.

Not sure what else is going on in the other issue, I haven't had time to look into that as well. It's just important to note, that $entity instanceof TranslatableInterface always returns TRUE - and that's most likely not what's expected.

Thanks for all the due diligence in this review!

As for the other issue, i'm adding some optional html wrapper logic for the formatters similar to the fences module. In starting that feature, I realized the existing formatter logic was over complicating things and needed to be more like core with the way the plugins get instantiated so I'm simplifying/standardizing the apis on those for cleaner and reduced code.