Views entity reference relationships must join on langcode for translatable entities

I think this has high relation to #2144377: Entity reference autocomplete lists entity labels only in current content language which is the form UI part of entering the reference itself. Whether you refer to specific languages or generally to an entity may be different use cases. I think Views should support fine-tuning the reference relation honestly.

changing version to 8.1.x
per https://www.drupal.org/core/release-cycle-overview#minor
and because this is a bug, (non-disruptive?) per https://www.drupal.org/core/d8-allowed-changes#patch

I think I've stumbled across the very issue and want to include my steps to reproduce my issue, just in case I've found a separate issue that needs to be fixed as well.

1) Create new node type (for example: referenced_page)
2) Navigate to admin/config/regional/content-language and set that node type to translatable
3) Create a piece of content of that node type (for example: This is the default language version of the referenced page)
4) Create another node type (for example: referencing_page)
5) Add an entity reference field to that node type that allows it to point to the referenced_page node type
6) Do NOT set that node type to be translatable (It doesn't actually matter if you do. You'll still run into the same problem. I'm just specifically addressing the point about having a non-translatable entity referencing a translatable entity. The heart of the issue is that the referenced entity is translatable).
7) Create a piece of content of the referencing page (for example: This is the default language of the referencing page)
8) Reference the first node type (for example, pointing to "This is the default language version of the referenced page.")
9) Create a block that uses: a contextual filter with a default argument of Content ID from URL; a relationship of "Content using {your_entity_reference_field}" and require the relationship; Title field (use the relationship) of referencing pages pointing to this referenced page.
10) Place the block in a region
11) Visit the "This is the default language version of the referenced page" node
12) Observe that there is only one title in the block
13) Add a translation "This is another language version of the referenced page"
14) Observe that the block now contains two titles.
15) Add another language to the site
16) Add a translation "This is a third language version of the referenced page"
17) Observe that there are now three titles in the block

Note: One workaround for the duplication is to use aggregation (for example Group column Entity ID or Language), although that's just masking the symptom and may have other undesirable side effects.

Hello, thanks for your work. I was checking the patch and I was wondering if the key for left field is correct. As I was checking the core I noticed that it should be left_field.

I noticed this problem when trying to create a view as described on #16
Maybe the patch #14 fixes the problem on some use cases, but for sure it doesn't fix it when there's a situation like described on #16.9

I'm providing a patch that fixes the use case as described on #16 but without tests since it would be nice to have other inputs on this.

I rerolled the patch #14, combined it with #19 and addressed the feedback from #18.

I experienced this issue as well with 8.7.5.

In my situation, the patch didn't work. It appears to me that the patch assures that the langcode of the field is the same as the langcode of the referenced entity (?).

The solution for me was to make sure the langcode of the field was the same as the user's currently selected language. The code that solved it for me is:

<?php
function my_module_views_query_alter(\Drupal\views\ViewExecutable $view, \Drupal\views\Plugin\views\query\QueryPluginBase $query) {
  switch($view->storage->id()){
    case 'my_view';
      // Get the currently selected language code
      $langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();

      // Add a condition to the query to only select entities referenced in the current language
      $query->addWhereExpression(0,'node__reference_field.langcode = \'' . $langcode . '\'');
      break;
  }
}
?>

Not sure how I feel about this solution, but needed something to work.

Below code worked for me

/**
 * Implements hook_views_query_alter().
 */
function my_module_views_query_alter(ViewExecutable $view, QueryPluginBase $query) {
  if ($view->id() == 'my_view_id') {

    // We need to filter multiple translation and restrict it only to
    // the current language.
    $language_condition = [
      'field' => "node__my_field.langcode",
      'value' => \Drupal::languageManager()->getCurrentLanguage()->getId(),
      'operator' => "=",
    ];
    $key = count($query->where);
    $query->where[$key - 1]['conditions'][] = $language_condition;
  }
}

Update to patch 22, to make it work with Drupal 9.2.x.
I also added an extra test check.

I also updated the summary with the use case described at comment 16

Comment 24 and 27, it would be nice to understand what are the differences between your use cases and the described step-by-step

I'm facing the same issue when adding a relation to a feed view.

If statement in modules/views/views.views.inc:841 is triggered and i can confirm '$data["node__MYFIELD"]["table"]["join"]["node_field_data"]["extra"][1]["left_field"]' exists in a hook_views_data_alter().

Although when hitting \Drupal\views\Plugin\views\relationship\Standard::query $this->definition['extra'] does not exist anymore.

It is not a step-by-step description but i hope it helps.

Re-roll for 9.5.0

Hi,
I tried the last patch #34 but it has no impact with tables commerce_product_field_data and commerce_product_variation_field data. The join query has only the product_id but no langcode is present.

UPDATE: I tried a simpler scenario where I have in view only the product title and brand. Brand is a taxonomy term that is translatable and it is an entity reference in Product entity. Unfortunately there is the same issue. langcode does not take place in JOIN statement.

This doesn't work, at least with commerce.

I found out that due to this issue https://www.drupal.org/project/drupal/issues/2930736 if change from the patch #34 the variable $field_definition --> $field_storage_definition, it works.

Moving back to Needs work for automated test coverage.

Patch on #34 works for me on Drupal 9.5.2. Thanks @Piotr Pakulski!

I could not reproduce this issue on my D10.1.1 installation.

My last comment #39 is false. I tested again and I have duplicated values. Also the patch in #34 could not be applied.

Re-roll for drupal 10.1.1

#34 works perfectly, what a relief. This was causing so many issues in our project. Thanks!

This is a very real issue and the patch in #41 solved my problem.