Add option to only list referenced entities in current language

+1 for this fix

So I was trying this patch, and for me it doesn't work out of the box. For it to work for me, I had to move the buildEntityFieldQuery part to before the if(isset($match)) part, like so:

protected function buildEntityFieldQuery($match = NULL, $match_operator = 'CONTAINS') {
    $query = new EntityFieldQuery();
    $query->entityCondition('entity_type', $this->field['settings']['target_type']);
    if (!empty($this->field['settings']['handler_settings']['target_bundles'])) {
      $query->entityCondition('bundle', $this->field['settings']['handler_settings']['target_bundles'], 'IN');
    }
    $entity_info = entity_get_info($this->field['settings']['target_type']);
    if (module_exists('i18n') && $this->field['settings']['handler_settings']['filter']['language'] == 1 && $entity_info['translation']['locale'] == TRUE) {
    	global $language;
    	$query->propertyCondition('language', $language->language);
    }
    if (isset($match)) {
      $entity_info = entity_get_info($this->field['settings']['target_type']);
      if (isset($entity_info['entity keys']['label'])) {
        $query->propertyCondition($entity_info['entity keys']['label'], $match, $match_operator);
      }
    }

I was looking around but couldn't figure out what the $match variable stands for exactly.

Also, the commited patch filters by the users current session. Using your use case, should you be editing a content in language A but your session/user/whatever is set to language B, you will end up associating an event translated to A with a location translated to B.

In my particular case, I need to filter by the parent node language instead of the user language, so I made the following aditional changes (based on my previous post)

protected function buildEntityFieldQuery($match = NULL, $match_operator = 'CONTAINS') {
    $query = new EntityFieldQuery();
    $query->entityCondition('entity_type', $this->field['settings']['target_type']);
    if (!empty($this->field['settings']['handler_settings']['target_bundles'])) {
      $query->entityCondition('bundle', $this->field['settings']['handler_settings']['target_bundles'], 'IN');
    }
    $entity_info = entity_get_info($this->field['settings']['target_type']);
    if (module_exists('i18n') && $this->field['settings']['handler_settings']['filter']['language'] == 1 && $entity_info['translation']['locale'] == TRUE) {
    	$node = menu_get_object();
    	$query->propertyCondition('language', $node->language);
    }
    if (isset($match)) {
      $entity_info = entity_get_info($this->field['settings']['target_type']);
      if (isset($entity_info['entity keys']['label'])) {
        $query->propertyCondition($entity_info['entity keys']['label'], $match, $match_operator);
      }
    }

Since I'm a Drupal noob, I ask that someone take a look at this to see if I made any stupid mistake.

Hi there, thanks for the patch, but we are not going to support this.

If the list of entities you are referencing is different between languages, you should make that field translatable, and use an UI (for example the one provided by Entity Translation) to edit the different language versions.

I really like the functionality that this patch proposes and think that this feature should be considered for this module, even if field translations are used as stated above because even with a translated field the autocomplete list has all your nodes of every language which has issues from a usability perspective.

That being said I have been testing this patch and have found there are still a few issues - kudos for the effort though! I have a bilingual site with nodes which are translated using node translations and I also have a localized (not translated) taxonomy vocabulary. Both the nodes and the taxonomy terms have a field collection with an entity reference field, the field collection for nodes is not translatable but the field collection for terms is translatable. And in both cases the reference field is not translatable because it makes no sense to do that for a field collection.

Using the patch above, the following cases are problematic or not covered:

1. when adding a node translation the url looks like this: eng/node/add/page?translation=23&target=fr which means that $node = menu_get_object(); returns null and the ER field defaults to English when the user needs to add French references. The translated node has to be saved and then re-edited to add French node references.

2. Taxonomy term references are always shown in the user's current language for the same reason as above - $node = menu_get_object(); returns null. The user then has no way of adding references to French content.

I don't think there is an easy answer for the situation that I have outlined above, but I do believe that further dialogue is required on how an ER field should behave in a multi-lingual environment. Cheers.

Here is a slight modification to the patch to use i18n_node_i18n_context_language() to find the corrent language context, which addresses #1 from my comment above. Also, for anyone else that runs into it, you need to save each entityreference field on your content type after adding this patch or you will get an error Undefined index: filter in EntityReference_SelectionHandler_Generic line 235.

I might be missing the point of this issue but what does this patch provide that is not provided with the Multilingual select module which comes with the i18n project?

I actually found this issue when looking for a solution to another, yet related, problem; I wanted that once a referenced item in language X is referenced by a given X language the next will happen: when translating the referencing item to language Y there will be no need to reference manually to the translation of the referenced item, that is, to an item of language Y, it will be done automatically.

This is maybe why it kept failing testing:

entityreference-language_filter-1462766-21.patch:11: space before tab in indent.
    	$form['filter']['language'] = array(
entityreference-language_filter-1462766-21.patch:12: space before tab in indent.
    			'#type' => 'select',
entityreference-language_filter-1462766-21.patch:13: space before tab in indent.
    			'#title' => t('Language handling'),
entityreference-language_filter-1462766-21.patch:14: space before tab in indent.
    			'#options' => array(
entityreference-language_filter-1462766-21.patch:15: space before tab in indent.
    					0 => t('Select all nodes'),
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.

Rather then patching Entity Reference itself, I've implemented the code in #21 into it's own module. Entity Reference conveniently uses the CTools Plugin API thus making the widgets extensible as plugins.

A solution which also adheres to the remark by Damz in #19.

Module is called Translated Entity Reference (for lack of a better name)

See: https://drupal.org/sandbox/netsensei/2168701

Thanks, @netsensei: the module (now called https://drupal.org/project/translated_entityreference) is a perfect solution for this problem!