"Content language of view row" rendering option does not always ensure row language is present

It isn't very clear what this filter does

Its not a filter. You already have your results when the rendering happens, it does not filter. It merely decides what language to use for the rendering as a primary target (and fall back from there if that is not available).

As a workaround, we started changing the setting to "Content language selected for page".

What was your original settings combination of filter/rendering?

Instead it is good with using the filter "Content: Translation language”. It would be great if there was some explanation on how the rendering language options work. If the "Content language of view row" it could also check for the "Content: Translation language" filter to exist and if not output a warning.

What should it warn you about? What did not work in your combination of configuration that you expected to work?

BTW we also have #2494907: Explain and improve the usability of dynamicly selected languages :)

So I retitled the issue to "Content language of view row" rendering option does not always ensure row language is present because that is how it sounds like. I believe this code is supposed to ensure that there is a langcode field proper in the query from the TranslationLanguageRenderer row plugin:

  public function query(QueryPluginBase $query, $relationship = NULL) {
    // There is no point in getting the language, in case the site is not
    // multilingual.
    if (!$this->languageManager->isMultilingual()) {
      return;
    }
    // If the data table is defined, we use the translation language as render
    // language, otherwise we fall back to the default entity language, which is
    // stored in the revision table for revisionable entity types.
    $langcode_key = $this->entityType->getKey('langcode');
    foreach (array('data_table', 'revision_table', 'base_table') as $key) {
      if ($table = $this->entityType->get($key)) {
        $table_alias = $query->ensureTable($table, $relationship);
        $this->langcodeAlias = $query->addField($table_alias, $langcode_key);
        break;
      }
    }
  }

Is this a node view? If not, does this entity have its data table, etc. defined so this logic will find it? In other words, is there a problem in this logic or in your entity definitions? :) This logic from the looks of it should ensure the row has the right language (if the entity had a data table), but will indeed render in the source language if the entity only had revisions but no data table or no revisions at all.

I'm confused why this isn't still "postponed, maintainer needs more info" because it seems like we need more information about what kind of view this was?

Sorry I've been told over IRC that it was a node view, so the default logic should have worked. I asked for query debug info, so we can see what is in the query if the field is not there... So for that, this needs more info.

possibly related issue #2457999: Cannot use relationship for rendered entity on Views

I tested this today on the latest Drupal 8 code. What I did:

- Install with Standard profile in English.
- Turn on the 4 multilingual modules.
- Add Spanish language.
- Make Node translatable (both content types).
- Add an English Article node translated to Spanish, and a Spanish Page node
translated to English.

Then I made a view of nodes. I added a Page display that displays Teasers, and a Block view that displays fields (and I added the Title and Body fields to the view).

Both of them have the default "Content language of view row" rendering option under Languages. Neither of them has a language filter. Both of the displays work fine.

So, I am unable to reproduce this, and I am assuming that one of the many Views-related bugs we fixed in the past few months fixed this issue.

If the issue is still a problem, please change the status back to Active, and provide more information on how to reproduce the bug, such as an export of the view (which you can get from the Configuration Manager page under Export), and/or more information on how you made the view. Thanks!

I am facing this issue after updating drupal core from 8.3.2 to 8.4.2.

Any solution ?

Please see comment #10... If you make a view following those steps, do you see the same thing that I saw two years ago when I marked this issue "Cannot reproduce"? If not, see the last paragraph of #10 and please export the view, save it in a text file, and attach it here. And provide some explanation of how you reproduced the bug (content types, content in your system, languages, etc.). Thanks!

Alternatively, if you decide that your problem is somewhat different from what is described in #10, then you might consider creating a new issue. If you do that, please describe the view and content types you created (export the view if possible), what you expected to see, and what you saw instead. Without clear steps to reproduce, it's very difficult to investigate, much less fix bugs. Thanks!

Hello!
It seems that I'm facing this issue, or doing something wrong.

Drupal 8.4.2.
I have two language enabled: English (en) and Ukrainian (uk), Ukrainian is default for site.
I created one node with translation, uk - original, en - translation.
Content is displayed like it is supposed to: if uk is selected as interface language, then uk version is displayed, and if en is selected as interface language, then en version is displayed.

I made the view according to the user guide: https://www.drupal.org/docs/user_guide/en/views-create.html , and translated it.
Fields to display are Title and Body (both translatable). Filter criteria: published == yes, content type == My Content Type.

And here is what I get depending on Rendering Language:

• Content language of view row: two rows, one for each language, en and uk, no matter which interface language is selected;
• Original language of content in view row: two rows, both are in uk, no matter which interface language is selected (node's original is uk);
• Site's default language (Ukrainian): two rows, both are in uk, no matter which interface language is selected (site's default is uk);
• Interface text language selected for page: two rows, both are in selected interface language, as if en is selected, both rows are in en, if uk is selected, both rows are in uk;
• Particular language selected, eg. Ukrainian/English: two rows, both are in selected language, eg. Ukrainian/English.

So it looks like it works... but not the way I expect =)
Could you please advice me what to check or configure? Thank you!

Addition:
if I add filter: "Content: Translation language (= Interface text language selected for page)" than view works as expected! So until I face other issue, I will consider this configuration as a workaround. Although there is no fall back to node's original language if it wasn't translated =(

I have found another workaround here https://drupal.stackexchange.com/questions/192782/how-do-i-get-views-con...

1. Add the "Default Translation" filter to a view. That basically ensures that all your nodes are shown once because each node can only have one default translation.
2. Select "Interface text language selected for page" for "Rendering" language. That will attempt to display the site in the current language and fall back if that's not available. (Interface text sounds a bit misleading, but unless you explicitly enabled separate content language negotiation, that's the same as the content language).

It seems to work!

Thanks akupaka - works perfectly !
Now I struggle with this: I let the nodetitle link to his content. But the Link-Builder builds the link dependant of the language - not depending on the active language, so if I click on an untranslated link I change my language to this ("original"-) language.

(but this belongs to https://www.drupal.org/project/drupal/issues/2802311)

kle, I have the same trouble. Don't have any idea how to resolve this.
I'd like to have page opened as it is (untranslated), but not interface language changed.

The workaround in #15 works, thank you akupaka!

But it feels like not quite the way we should have to do it, that we expect to do multilingual views in Drupal 8 and Drupal 9? Had to do this on a view listing taxonomy terms.

My example is with taxonomy term Relationship (the classic Taxonomy term node views), and I wanted to share what worked for me since it can be useful to others @mlncn

I couldn't get the Views to work with the "Default translation" (set to True) no matter what Rendering option was chosen. I would get duplicates in results, no matter what the interface language, and all node translations would display.

For me the winning combination is the "Content: Translation language (= Interface text language selected for page)", and after you add the taxonomy term Relationship "(field_tags: Taxonomy term) Taxonomy term: Translation language (= Interface text language selected for page)".

So I needed both of these when the Relationship is present. And also: "Rendering Language: Interface text language selected for page".

My use case is to only show content that is in the current Interface language, without fallbacks for content that don't have translations.