Rendered entity is not language aware

Nothing we can do until #1178500-14: hook_field_*() prepare/view have no access to the requested language is fixed.

Would you mind sharing your approach to "hacking something in" to tackle this problem? I've got exactly the same issue; I need to filter out referenced entities that are EN on pages that are FR.

Hey.

I have the same issue and I am also looking to find a solution. It is a bit hard because it seems there are a lot of such issues, and anyway the different language settings are pretty hard ( a lot of different possibilities).

I am also testing some modules, which perhaps can help. I will post here any more information when I am able to produce a correct output. (so I am also checking for views/blocks etc. because the rendered entity was no success until now.)

Cheers

Ey peoples. It looks like I found a way with views creating me a block showing entity translated terms correctly.
But this is not specially related to entity reference, but perhaps a temporary or alternative solution.

For my use case I did this to show connected terms, but I think there are also possibilities for referenced "Nodes" or referenced entity's.

Just to show you what I got, including an export of the view. If you need more information or have problems let me know. I will perhaps investigate also other use cases for displaying entity translations.

Short note how to do it:

- Create a view to show terms
- add relationship "Entity translation: translations"
- add filter Entity translation: Language (=Current user's language) -> if you want to show the current language

With these filter options you can already create your content as you like.

For my use case I added also an contextual filter to relate to the current displayed node
And also some more magic happens with the Relationship "Content with term" which filters for only selected terms.

Some images and view export are attached.

This will already allow to show content where you want. If you use Display Suite you can really use this wherever you want.

Any feedback is welcome!

Here's a workaround that seems to be doing the trick for me for now:

In entityreference_field_formatter_view(), stick in a block of code that grabs the language from the global $language variable:

...

    case 'entityreference_entity_view':

      global $language;
      if ($langcode == LANGUAGE_NONE && isset($language->language)) {
        $langcode = $language->language;
      }

      foreach ($items as $delta => $item) {
        // Protect ourselves from recursive rendering.
        static $depth = 0;
        $depth++;
        if ($depth > 20) {
          throw new EntityReferenceRecursiveRenderingException(t('Recursive rendering detected when rendering entity @entity_type(@entity_id). Aborting rendering.', array('@entity_type' => $entity_type, '@entity_id' => $item['target_id'])));
        }

        $entity = clone $item['entity'];
        unset($entity->content);
        $result[$delta] = entity_view($field['settings']['target_type'], array($item['target_id'] => $entity), $display['settings']['view_mode'], $langcode, FALSE);
        $depth = 0;
      }
      break;
  }

So as to avoid hacking entityreference, I stuck this version in my own module with my own definition in hook_field_formatter_info().

That workaround seems to work for now. Thanks JoelRosen, but right I can only get it working hacking it in into the contrib module. Could you explain how you implemented it with the hook_field_formatter_info() ?

I just made duplicates of all the hook implementations that entity reference provides. So just copy entityreference's implementations of the following hooks:

hook_field_formatter_info()
hook_field_formatter_settings_form()
hook_field_formatter_settings_summary()
hook_field_formatter_prepare_view()
hook_field_formatter_view()

Change the names for your custom module and any other tweaks you need. Anyway I'm not actually sure if you even need to implement all these hooks.

Guys, please help #1178500-14: hook_field_*() prepare/view have no access to the requested language get in. There is nothing obvious we can do until this is fixed.

Just ran into this with a project. When using entity translation with entity reference, you don't want to enable translation for your reference fields, which means all the field data gets saved with the LANGUAGE_NONE language. Calling field_view_field() on a node with this reference field with $language not provided (meaning to use the current language, let's say 'fr' for French) means that by the time we get to entityreference_field_formatter_view(), $langcode is actually LANGUAGE_NONE and so the referenced entity is not rendered using French.

Having a fix in entityreference would be nice because in the mean time we not only have to patch entityreference but also core. Patch attached in case anyone else finds this useful.

#14 is basically a hack, but I guess it improves the situation in most use cases.

Let's make this behavior configurable (in the formatter settings), and get this in.

I added a formatter setting to Dave's patch.

Thanks everyone..

I wouldn't really be happy with having to enable this every time when it should be automatic if $langcode = LANGUAGE_NONE. Is there a way this can be configurable but enabled by default or more automatic?

#17 worked well for me (and saved the day!).

I still do not think that this should be disabled by default and committed as-is. An core fix has no momentum, and any multilingual site will have to go through and re-edit all their entity reference field configurations.

I changed the default value of the formatter setting to TRUE - according to Dave's comment in comment #18.

However as there probably is no real use case for NOT using the the content language for the rendered entity, I think Dave's original patch from comment #14 is also fine.

Thanks a lot for looking into this. After applying patch #22, checking the new setting, clearing the cache, this solved my issue!

This patch fixed an issue for me where I have a node translated content type that references another one that was entity translated.

After applying the patch in #22 entityreference does indeed fetch the correct language version of the entity translated target.

Patch #22 fixes the issue also for me.

IMHO the patch is RTBC

Patch applies cleanly against latest dev and fixes a big issue with entity translation.

Too bad this did not get in before the security release that came out this morning. What's the perspective for the next stable release?

Does not work for me, unfortunately...

I have a content type with a multivalue field containing references to other nodes in the same content type. I took the current dev of the module, applied patch from #22, set the formatter to "Rendered entity" and pointed it to a view mode of the content type where only a linked title is enabled.

Cleared all caches.

Still, the multivalue entity reference field points to nodes in all sorts of languages, even though the current node is in EN. Using URL path language recognition, also for the default (English) language.

@Vacilando: I have a similar environment (using Entity Translation, not i18n) and the patch works fine. Make sure that you DO NOT have translation enabled for the Entityreference field itself; all the translatable fields from the referenced entities will be shown in the current user language.

#30: Re-rolled patch #22 against the current 7.x-1.1 release.

Patch #30 works for us!

Patch #30 works great for me also.

Can this be committed please?

Thank you very much

Confirm patch #30 seems to be working well

#30 is a nice patch.

#30 works for me (required clear cache)

Working great after applying #30.

Just one thing: if Use current content language is not checked in the display settings for the field, I get a PHP Notice complaining about use_content_language not being set, in line 1273 of entityreference.module.

In line 1273, defaulting to use current language gets rid of the notice, but I'm not sure if it's a good idea:

if ( (empty($settings['use_content_language']) || $settings['use_content_language']) && !empty($GLOBALS['language_content']->language)) {
  $langcode = $GLOBALS['language_content']->language;
}

Otherwise, checking for the key would get rid of the notice:

if (!empty($settings['use_content_language']) && $settings['use_content_language'] && !empty($GLOBALS['language_content']->language)) {
  $langcode = $GLOBALS['language_content']->language;
}

Recreated the patch as it was not applying on latest 7.x-1.x-dev
using the apply patch from netbeans IDE (maybe because of line numbers)
here is the new patch but exactly the same as #30

I also confirm that it works as advertised

please commit there is a lot of evidence above that it works as advertised

OK maybe its not needed
but in my system it was not applying

I wish this would just get committed, I've been using variations of this exact patch for over a year now...

Pobster

#42 re-rolled.

Added a condition that prevents the notices that occur until the formatter settings aren't re-saved

I ran into this problem as well. My observations:

- #14/@Dave Reid is correctly explaining what is going on.
- For most fields this is the correct behavior, thus IMO no bug in core, but for entityreference this poses a problem of loosing the language in which to render the referred entity.
- So a solution should be in entityreference.

Should the solution be applied when LANGUAGE_NONE is passed in (@Dave Reid) or based on a setting (#16 Damien Tournaud)?

The only case I can think of, where the result could differ, is when having a double reference a -> b -> c, where b is not available in the language a is being sdisplayed in (the content language), but c is available in both the content language and the default/fallback language of b. What language do we want c to be displayed in? If we make it configurable we can choose, otherwise it will always be the language of b.

Thus making it configurable leaves the choice to the site builder. So I prefer the patch as it currently is (#45).

I reviewed and tested that patch. so the RTBC as set in #42 is now an RTBC for patch #45.

Note: workaround is setting the field to translatable, but that might loose sync between the different languages when changing the reference (not when initially setting the reference in the main language before translating the entity).

I have also applied patch #45 and seeing it resolve the issue.

#45 worked well for me as well

Using the patch #45 for a while now. No problems.

Would be great if this could finally get committed. If you got reference fields within a feature this is messing up the feature states.

There's a problem with this patch... it checks the right entity language but if I use entity translations without the language fallback it show the white entity instead. I think it should check if at least a field is in the current language, for example the Title Field...

#45 resolves the issue, but I agree with #50 that because it's not committed feature behavior changes, so I'm a little uneasy to apply this.

#45 resolves the issue and works well since months in a pair of production sites.

Please commit this.

Thank you very much

This also works for me.

This doesn't work if your administration language is set to be one language, even with translated content. This is because to when you edit translated Nodes they don't default to the translated language, they stay in English using a standard URL, not one with the language code at the beginning. This is causing only English content to show up in the entityreference field.

#45 resolves the issue for me.

#58 worked great in my case.

Patch in #58 works like a charm. Thanks!

I reviewed the code and looks ok.

#58 works for me too. I hope this gets committed soon!

#58 is also working for us in several projects :)

But we need tests.

#58 works for me on 7.x-1.1

This is a quick and dirty fix for people who need this linking to the current language version of the node NOW like me.

for non-dev version: 7.x-1.1

add the following after line 1267 in entityreference.module or if that isn't right for whatever reason under the "case 'entityreference_entity_view':" after "unset($entity->content);":

if (isset($entity->tnid) && !empty($entity->tnid)){
	global $language;
	$translations = translation_node_get_translations($entity->tnid);
	
	$entityBackup = $entity;
	
	if ($entity = node_load($translations[$language->language]->nid))
		$item['target_id'] = $entity->nid;
	else
		$entity = $entityBackup;
}

Again this was a quickly done fix because I don't have time so use at your own risk.

#58 works also for latest 7.x-1.x-dev

#58 works for me to on 7.x-1.1

#58 worked for me too.

Just tested and #58 works like a charm.

I have been struggling with this also for a while. Based on all patches and comments i have made my own patch which is working for all formatter types, because i use "Label" formatter a lot. The thing i did is that i load and replace the target entity with the translation entity. My patch is working only for nodes so be aware if you decide to use it.

That's a nice approach for nodes, but we shouldn't display such a patch in the issue summary :)

#58 worked for me too.

I've re-rolled #58 providing test coverage for the "Rendered entity" formatter being language-aware.

The test class enables a feature called "entityreference_entity_translation_test" which sets up what's required required to test the functionality at hand (e.g. adds a reference field to the article content type, sets the reference field formatter to "Rendered entity", and so on), then it creates 3 translated article nodes along with their references and tests that the formatter behaves correctly.

Re-rolling after adding dependencies to EntityReferenceEntityTranslationTestCase::getInfo().

The test runs locally, and it was a re-roll of an RTBC patch. Lets see if the testbot tests only RTBC patches.

Patch #58 worked for me.

Posting re-rolled #58 which includes tests.

Wow, thanks for the tests!

Can it do fallback when no translation of referenced entity available?

Patch and tests tested : it works fine!
Thanks @ademarco

+1 for RTBC

We are also using the patch from #58 and #85 in several projects. Works fine, please commit :)

Me too: RTBC++

Another confirmation - Patch #85 working correctly and solves the issue!

Any chance we can get this committed? It seems we have receives quite a few positive RTBCs. Thanks!

Removing the "needs tests" tag since tests are now included.

I hope that helps to get the module maintainers aware of that issue.

Confirmation here too,
Patch #85 is solving my issue with taxonomies as entity reference fields.
Taxonomy fields are now correctly translated on the parent node (with entity translation)

I've found a problem with #85. It works correctly if a node hasn't a translation, but it fails when a node has a translation AND this translation is unpublished.

Someone else can confirm this problem?

Applied patch from #85 to a clean 7x.1x-dev and got a rejected hunk from the patch regarding tests:

Checking patch entityreference.info...
error: while searching for:
files[] = tests/entityreference.taxonomy.test
files[] = tests/entityreference.admin.test
files[] = tests/entityreference.feeds.test

error: patch failed: entityreference.info:22
error: entityreference.info: patch does not apply
Checking patch entityreference.module...
Hunk #2 succeeded at 1140 (offset 1 line).
Hunk #3 succeeded at 1172 (offset 1 line).
Hunk #4 succeeded at 1266 (offset 1 line).
Hunk #5 succeeded at 1279 (offset 1 line).

All the same - the hunks that worked fixed the problem for me! I was unable to reference entities unless they were all language neutral. Now I am able to reference as long as they are in the same language, translate etc.

I also checked my site for #97's issue with published vs. unpublished references causing any failures.

I think aside from the error with the patch, this has fixed the problem.

This is a simple reroll.

The patch on #99 doesn't work for me. Let me explain:

Testing latest version of patch on #99 with simplytest.me button:

1) I create a new Entity Reference field named "Articles" on "Basic page" that references "Articles" with widget "select list". Unlimited values.
2) I enable "Content translation" module
3) I edit "Article" and "Basic page" content types to enable "Multilingual support" with option "Enabled, with translation" (both content types)
4) I enable Spanish language on admin/config/regional/language
5) I create a new Article named "Article EN" with language English selected
6) I create a new Article named "Article ES" with language Spanish selected
7) I create a new Basic page named "Basic page ES" with language Spanish selected. I see both "Article EN" and "Article ES" on "Articles" Entity Reference field => I consider this is correct because the node is not yet saved. However, something could be done with AJAX to filter options once language select changes.
8) Now I edit the recently created "Basic page ES" and I can still see "Article EN" => I consider this is wrong because "Basic page ES" has Spanish language selected.

Am I missing something?

@rcodina

This issue here is not related to your observation - as far as I can see.

This issue deals with rendering of a referenced entity, which is translated in multiple languages (using Entity translation and not Content Translation). In that case the language of the parent entity is not passed on correctly to the rendered entity.

Please search the issue queue for an issue, which fits your problem description - or post a new issue if you did not find any other matching.

Thanks,
Walter

@valderama Ok, I've opened a new issue.

Since the problem raised in #100 seems to be unrelated to this issue I'm marking this as RTBC again.

@ademarco What about the problem raised in #97?

I'm not sure what #97 is about.

It works correctly if a node hasn't a translation, but it fails when a node has a translation AND this translation is unpublished.

With entity_translation Publishing Options are for all Languages, so if a translation is unpublished the node is not accessible and entity_reference shouldn't display anything.

Tested on simplytest.me with Entity Translation 7.x-1.0-beta4 and Entity Reference 7.x-1.x.

Just to add that patch #99 applies cleanly and fixes the problem for me. +RTBC

I also did some testing and reviewed the code. I consider this patch good to go into the main branch.

+1 for RTBC + commit ASAP. Thank you all!

+1 RTBC, and indeed commit plz :D Thanx!

+1 RTBC (#58 worked for me).
Yet another issue that lasts 4 years to be committed.

+1 RTBC
patch #99 works for me! Thank you!

Removed ".info" part due "error: entityreference.info: patch does not apply"

Rerolling my patch from #99.

This should fix the tests - 7.50 added a new permission for fields that needed to be added to these tests.

I tested it with Simplytest.me on Drupal 7.50 and also on 2 other drupal sites of different version and I confirm that patch works perfectly for me.

There's a "return;" in the last patch, I'm not sure where that came from (I haven't dug through each patch to find it) but I'm concerned it would have unintended consequences. Can someone please comment out that line and try the tests again?

Ran into this bug today on a client site. Patch works, seems well tested. Committed to dev.

@DamienMcKenna With or without that return didn't seem to have an effect from what I could see. Continued to work. So I left it as is. Nm, different return value. I'll update the patch for the test.

Tracking that as a separate issue here: #2789493: Investigate stray "return;" in admin.test file

Would be cool to have a new stable release if this patch works for longer time... for i18n pages this is quite important.

Thank you all so much!

Wow! Great to see this committed. I have added a patch four years ago in comment #17 :)

Happy!

I desparatly ran in this issue today and was glad to find a patch here. I tried to apply I without success.
Can someone help with the patching please?

That's what I tried:

1. I went to the version control page and downloaded the version 7.1-1.x via terminal:

git clone --branch 7.x-1.x https://git.drupal.org/project/entityreference.git
cd entityreference

2. Then I downloaded the patch from comment #115

wget https://www.drupal.org/files/issues/entityreference-n1674792-117.patch
wget https://www.drupal.org/files/issues/entityreference-n1674792-117.interdiff.patch

3. Then I tried to apply the patches with
git apply -v entityreference-n1674792-117.patch

and I get the error messages "...patch could not be applied".

By comparing the lines and replacements between patch and the downloaded reposititoy I see many mismatches, therefore I assume, that I did not get the right version in the first step... :(

Where do I get the version on which patches are based on? Thank you in advance for your help.

@HydroZ The patch does not apply because it has already been committed and is part of 1.2 release.

What you are doing is getting the latest dev (which includes 11 more commits after that patch was committed, basically 1.2 + 10 commits).

So you have 2 choices:

1. Get the latest dev as is
2. Get the latest stable release (1.2)

@ptsimard Thanks a lot for your answere. I think now I understood the whole procedure of patches and versions a bit better.

Are you really sure that the patch has fixed the error?

My current situation:

Exactly the same as #1 => I am working with entity field translation. Some fields are set to be translatable. To make the title translatable the "title field" module is enabled.
Content Type B has an entity reference field (select field with entity titles) but it shows only entities with translated titles (field title_field). The entities language itself does not matter.

A entity with the following field value would be available in the entity reference field:

$node->title_field = array(
   'de' =>  array(
      array(
         'value' => 'Title DE',
         ...
      ),
   ),
   'en' =>  array(
      array(
         'value' => 'Title EN',
         ...
      ),
   ),
);

So what can I do to make the et reference field show all contents (with translated titles and untranslated titles)??
Or is the Issue still not fixed?