Translated entity references not rendered in the entity display language

Instead of all the changes done to EntityReferenceFormatterBase and its extending classes, couldn't we just write the logic of getAccessibleTranslatedEntity() in EntityReferenceFormatterBase::prepareView()? That's exactly the purpose of that method :)

The problem was that test bot installs Drupal in subdirectory, and $entity->url() returned the path with the prefix, also $this->drupalGet($path) added the prefix to the path before the request, so the real patch were double prefixed. I think it's some sort of bug in the test system.

Please see https://www.drupal.org/project/testbot, the testbots are installing Drupal in a subdirectory by design.

I tested the patch and it works fine for me.

I suggest rename EntityReferenceFieldViewTest to something clearer eg.: EntityReferenceFieldViewLanguageVariationsTest

When I translate a referred entity, and I not translate the "host" entity and I go to the "translated url" the host fallback English and refered entity also. If it is fine, I suggest write an another test for testing this usecase also. (If isn't, I suggest write a test for a good usecase and correct the patch.)

The default fallback behavior if the referenced entity has no translation.

I could see some cases, where we would like to have more granular control over the fallback behavior (like fallback chains), but of all the experience with client websites, every website is different. And the default language is suitable for most of cases. So I +1 that.

New method vs. prepareView()

I agree with @amateescu that prepareView() sounds a lot like what we would like to use, but the case that is made in #8 makes a lot of sense.
So +1 for the new method.

+++ b/core/modules/entity_reference/src/Plugin/Field/FieldFormatter/EntityReferenceFormatterBase.php
@@ -15,6 +18,62 @@
+    $active_langcode = $parent_entity->language()->getId();

Discussed this with @Gabor and @Désiré.
Also here I could see the case that on some websites would like to use the negotiated content language, rather the language of the parent entity.
But when the case happens that the parent entity is not translated the whole page will show anyway a big language mix. If we wanna fix that fully properly we should have an additional Language Negotiation system: Referenced Content Language Negotiation. But this would confuse so many sitebuilders even more (it's now already crazy). So I think this is a case for a contrib module.

Maybe rename $active_langcode to $parent_entity_langcode?

Right, I think #8 makes sense as well. And further to #20, we can now simplify the code even more, something like the patch attached (note that the interdiff doesn't show it, but the patch includes the change from #22).

I think that's mostly done for easy testing purposes and, since it's already the current HEAD behavior, this looks good to go now. Thanks Désiré!

can we get the changes from #22 back in there?

then I would also RTBC that :)

It's there allright :P

oh damn, ignore #32, this is already in, looks like the interdiffs are strange.

but found

+++ b/core/modules/entity_reference/src/Plugin/Field/FieldFormatter/EntityReferenceIdFormatter.php
@@ -30,21 +30,15 @@ class EntityReferenceIdFormatter extends EntityReferenceFormatterBase {
-    foreach ($items as $delta => $item) {
-      if (!$item->access) {
-        // User doesn't have access to the referenced entity.
-        continue;
-      }
-      if (!empty($item->entity) && !empty($item->target_id)) {
-        /** @var $referenced_entity \Drupal\Core\Entity\EntityInterface */
-        $referenced_entity = $item->entity;
+    foreach ($this->getEntitiesToView($items) as $delta => $entity) {
+      if ($entity->id()) {
         $elements[$delta] = array(
-          '#markup' => String::checkPlain($item->target_id),
+          '#markup' => String::checkPlain($entity->id()),

we're removing the check for if (!empty($item->entity) && !empty($item->target_id)). it's also not in getEntitiesToView().
Not sure for what that exactly is, but maybe $item->target_id can be empty?
But there is a check for $entity->id() which probably is true every as getEntitiesToView() will return an entity?

+++ b/core/modules/entity_reference/src/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
@@ -69,34 +69,30 @@ public function settingsSummary() {
-      if (!empty($item->target_id)) {
-        $elements[$delta] = entity_view($item->entity, $view_mode, $item->getLangcode());
+      if ($entity->id()) {
+        $elements[$delta] = entity_view($entity, $view_mode, $entity->language()->getId());

same here

ok, cotcha. thanks for the explanation :)

back to RTBC

1. +++ b/core/modules/entity_reference/src/Plugin/Field/FieldFormatter/EntityReferenceEntityFormatter.php
   @@ -69,34 +69,30 @@ public function settingsSummary() {
   +        // @todo Find some better solution for fetch '_attributes'.
   

   Can we get an issue filed for this and referenced in the code. See https://twitter.com/xjmdrupal/status/497852222600790016

2. +++ b/core/modules/entity_reference/src/Plugin/Field/FieldFormatter/EntityReferenceFormatterBase.php
   @@ -8,6 +8,9 @@
   +use Drupal\Core\Entity\EntityInterface;
   

   Not used.

I'm not sure why that @todo was introduced in this patch, that is the only way to access _attributes :)

Ok.. NR first.

What a lazy bot! Re-uploading.

Désiré, I just did that :P And I have no idea why the bot doesn't like that patch :/ Let's try with a different file name.

Committed bf44ce4 and pushed to 8.0.x. Thanks!

Related: #2405469: FileFormatterBase should extend EntityReferenceFormatterBase
Currently file/image formatters do not follow the correct translation behavior that was added for ER fields here.