Translation language base field handler should use views field handler, provide unified options

1. +++ b/core/modules/node/config/schema/node.views.schema.yml
   @@ -94,12 +94,12 @@ views.argument_validator.node:
   -  type: views_field
   +  type: views.field.node
   

   extend/reuse++

2. +++ b/core/modules/node/src/Plugin/views/field/Language.php
   @@ -41,11 +40,9 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
   -    // @todo: Drupal Core dropped native language until config translation is
   
   +++ b/core/modules/views/src/Plugin/views/field/LanguageField.php
   @@ -40,11 +39,9 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
   -    // @todo: Drupal Core dropped native language until config translation is
   

   @todo--

This is good to go.

+++ b/core/modules/node/tests/modules/node_test_views/test_views/views.view.test_language.yml
@@ -159,7 +159,6 @@ display:
-          link_to_node: false

hopefully, it won't come again as I can see it is there in core views configuration.

I tried this out in a Node view and it seems to be working fine.

I tried a Taxonomy view and it doesn't have this setting though on its language fields. Should it? Probably taxonomy has its own plugin, ugh. Is that out of scope for this issue? It seems as though if we have the option on generic language plugins and node plugins, we should have it for all of the language plugins.

And... Can we get rid of the specific entity language plugins and unify them possibly, rather than having 5 different ones or whatever we have?

I didn't see that taxonomy setting. If you use the field "Translation language" instead of "Original language", the Native Language box is NOT in the settings. ?!?

OK. So I got interested in the question of what the individual entity-specific Language plugins are doing that the base one in \Drupal\views\Plugin\views\field\LanguageField is not doing. (This plugin is the default field plugin used for all language fields on entities unless the specific EntityViewsData class overrides the plugin choice).

Here is a survey:

a) Taxonomy
- Uses \Drupal\taxonomy\Plugin\views\Field\Language (ID "taxonomy_term_language") as the plugin for the Translation Language field, but not for the Original Language field (which in itself is odd; the Original Language field uses the base Views plugin default).
- This plugin extends the Taxonomy field plugin. This gives it options to link to the taxonomy term page and to convert spaces in the name (in this case, the language name?!?) to hyphens.
- The taxonomy language plugin does not currently have the native language display option on it.
- To me, neither of the options from the Taxonomy plugin makes any sense for a Language field and I think we should get rid of this override and the \Drupal\taxonomy\Plugin\views\Field\Language plugin class entirely, and use the default base views plugin instead, which would give us the native language option for free, and make the two language fields for Taxonomy behave the same.

b) Node
- uses \Drupal\taxonomy\Plugin\views\Field\Language (ID "node_language") for Translation language, Revision Translation language, and Revision Original language fields.
- This plugin extends the Node field plugin, with the addition of a native language option.
- The Node plugin gives you the option to link to the node. Like Taxonomy, I don't really think it makes a lot of sense to link the language field to the node.
- So again I think we should just get rid of this language plugin and use the Views default language plugin instead.

c) User
- uses \Drupal\user\Plugin\views\Field\Language (ID "user_language") for the "Original language of the user information" field, but not for the other language fields.
- As usual this gives you a "link to user" option, see (a) and (b).
- Again I think we should drop this, and that would also make all language fields on User behave the same, since the others use the default plugin already.

d) Other entities: there are no [field][id] plugin overrides for user language fields that I can see in the other classes that extend EntityViewsData: AggregatorItemViewsData, AggregatorFeedViewsData, CommentViewsData, or FileViewsData,.

So... If we think that it's important for Language fields to have the "link to entity" option, we could add that to the base Language plugin. That was actually done for regular short text fields recently on #2387019: String field formatters cannot link to their parent entity. But that is all we would lose if we got rid of the 3 specific language plugins and switched to using the one default Views plugin. To me, this option doesn't seem all that important to have, but if we need it, it could certainly be provided. The way to do that, actually, would probably be to make a new field plugin called "entity language" with this option, and use that as the default for all language fields on entities in the base EntityViewsData class. (The base language plugin for Views as a whole doesn't know about entities.)

Anyway, thoughts? I don't think losing the "link to entity" option is a major problem, and unifying everything in one central plugin, and getting rid of 3 classes and several lines in those EntityViewsData customizations would be good.

Ah, good point. If the links actually are produced in the correct language, that would be a good use case. (I am not sure they do. At some point we should test this, once we're closer to having views actually working for multilingual... they may be working right but I'm just not sure. Actually I'll add this to the giant #6 on the Views meta.)

So, I think yes we should have a basic_language and language formatter. While we have no use cases in Core for the non-entity language, that is not conclusive because all our Views integration in Core is entities. Oh wait, we do have several things in Core that are not entities or fields that have views integration, like dblog and tracker... I don't see any language fields in any of them, but in theory someone could have a non-entity db table with views integration and a langcode column and want to have a language field, so yes I think we should keep a non-entity version around. Making its name basic_language and keeping language for the entity version would mean not having to change Core, so that does sound like the best idea with the least impact, since I think most views integration in d8 contrib is likely to be entities, right?

Onward!

Adding the ability to link back to the entity would also be consistent with the string decision: just put the checkbox on all "short strings". If it isn't used, it doesn't cost much.

And I think... wouldn't it be as simple to implement as having the entity language plugin extend the new entity-string-with-link plugin, rather than extending plugin base or the non-entity language plugin?

+1000 on this patch! I love that almost all of it is "remove stuff", and that most of the added lines are in a test, with a few lines added to make the "native language" functionality on the default Views language field actually work.

One thing I think this patch is missing is to remove also the 'user_language' custom field from UserViewsData? I see Node and taxonomy but not User.

And agreed we still need to decide whether the Language field needs "link to entity" on it. You can definitely use rewrites to do this... well probably anyway. I am not sure that rewrites would be easy to use to get a link to the entity in the correct language?

Looks good to me.

We need to do user as well as node and taxonomy, see #33. I guess I forgot to change the status.

I'm also not sure we decided it was OK to remove the ability to link language fields to their entity, which was present in the special fields for node, user, and language.

Ok, here is a patch that removes user_language field.

I'm also not sure we decided it was OK to remove the ability to link language fields to their entity, which was present in the special fields for node, user, and language.

Still need to address this one.

Right now there is no access checking at all for base entity fields, see #2385443: Test that base entity fields on views respect field level access. Once that is taken care of, which actually would be on #2342045: Standard views base fields need to use same rendering as Field UI fields, for formatting, access checking, and translation consistency, which will make all base entity fields rendered using entity formatting, I think we'll be OK.

The reason I think so is that if you've got a row that is entity X and you have no permission to view entity X, then you shouldn't be seeing *anything* in that row at all, including the language field, whether or not it is linked to entity X. So I don't see how that is a problem? It may not even be a problem now; hopefully views is not letting you see any results for entity X if you don't have entity view permissions.

@Gábor Hojtsy, reg: #37.2 - Looks like it is a copy/paste from parent class core/modules/user/src/Plugin/views/field/User.php. It doesn't look like related to language.

If we assume (not saying we should!) that we need to not lose this functionality of linking the field to the entity, how much would it take to make it happen? It seems like the answer is "not much":
- We'd need a specific entity language field handler class, which would either extend the existing "short text with link to entity" handler that was created recently and make it into a language renderer, or extend the existing "language that isn't entity" handler and make it link to the entity.
- We'd need to make this the default handler for language fields in the EntityViewsData base class, either by (a) giving this new one the "language" ID and giving the old non-entity one a different ID, or (b) by changing EntityViewsData. Probably (a) is easier.

I think that rather than debate whether we need this functionality or can afford to lose it, we should just do this.

The reason I think so is that if you've got a row that is entity X and you have no permission to view entity X, then you shouldn't be seeing *anything* in that row at all, including the language field, whether or not it is linked to entity X. So I don't see how that is a problem? It may not even be a problem now; hopefully views is not letting you see any results for entity X if you don't have entity view permissions.

... for those kind of access checking we always rely on query rewrite, so for example the hook_node_grants/records() system. This is taken care of.

Great work and great cleanup here!

+++ b/core/modules/views/src/Plugin/views/field/LanguageField.php
@@ -40,11 +39,9 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+    $languages = $this->options['native_language'] ? \Drupal::languageManager()->getNativeLanguages() : \Drupal::languageManager()->getLanguages();
+    return isset($languages[$value]) ? $languages[$value]->getName() : '';

Do we have field formatters for that? ... we would at one point need that, in case we really want to support it.

@dawehner: we already extended the scope based on what @jhodgdon suggested, I would avoid unifying it with field formatters as well here. The original scope was some views exposed settings that lied because they did not have any effect.

Well sure, it was more of a general question ... especially in the context of the base field formatter issue.

If I read the patch we already add a test.

I did a manual testing
-Enable all 4 multilingual modules
-Add a new language
-Translate the native name of the new language using config translation
-Add a new language field to the content listing view checking "Display in native language"
-Create nodes in different languages
-Check the language translation

without the patch the languages are shown in English
With the patch the languages are translated.

I also reviewed the code and fixed a couple of comments and an indent problem.

here it is

Great! #45 marked it RTBC. #46 was a reroll. Interdiff to the latest patch looks good, and there was a manual test even. And I agree that the patch looks good, so I'm also +1 on RTBC.

However:
- The issue summary doesn't seem to match the patch.
- We need a beta evaluation added to the summary.

Looks like the patch doesn't apply now...

Regarding not having a non-entity Language field available in Views... I am not sure whether or not that is OK. For other fields, Views has maintained non-entity versions for base database data. But maybe Language is so entrenched in our entity system that having a langcode field in a non-entity table doesn't even make sense?

+++ b/core/modules/views/src/EntityViewsData.php
@@ -300,7 +300,7 @@ protected function mapSingleFieldViewsData($table, $field_name, $field_type, $co
       case 'language':
-        $views_field['field']['id'] = 'language';
+        $views_field['field']['id'] = 'field';

So I guess we still need to drop this change for now, right?

Looking good!

Nitpicks:

a)

+  public function settingsSummary() {
+    $summary = parent::settingsSummary();
+    if ($this->getSetting('native_name')) {
+      $additional_summary = $this->t('Displayed in native name');

This last line should be "Displayed in native language". oops.

b) I don't think settingsSummary() is returning a value? oops. [Oh, you fixed that in the latest patch while I was reviewing, good!]

c) I'm unclear on why core/modules/views/src/Plugin/views/field/LanguageField.php changed the setting machine name from native_language to native_name? I guess it was for consistency with the Field API plugin, but it seems like most of the previous specific Views plugins like node_language used "native_language" as the setting name too. Why make this change? I don't see any discussion above, and I don't see "native_name" anywhere in Core prior to this patch.

@dawehner suggested that I add a comment here that it would be useful to be able to print out the language code and not the label (For example, in feeds and other kind of data exports). Maybe add that as an option here while all this stuff is being worked on. Or some sort of output rewriting, does not have to be easy, just possible :)

I think the problem is language_entity_field_access(), see interdiff.

It at least let more of the tests pass, some still have a different behaviour, but I have seen similar problems in the other issue as well.

I don't really feel qualified to vet the approach or actual code, just one minor remark :

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/StringFormatter.php
@@ -127,7 +128,7 @@ public function viewElements(FieldItemListInterface $items) {
       // The text value has no text format assigned to it, so the user input
       // should equal the output, including newlines.
-      $string = nl2br(String::checkPlain($item->value));
+      $string = $this->viewValue($item);

The comment would now be more relevant in the class' implementation of viewValue() :-)

+  public function settingsSummary() {
+    $summary = parent::settingsSummary();
+    if ($this->getSetting('native_language')) {
+      $additional_summary = $this->t('Displayed in native language');
+      if (!empty($summary['#markup'])) {
+        $summary['#markup'] .= '; ' . $additional_summary;
+      }
+      else {
+        $summary['#markup'] = $additional_summary;
+      }
     }
+    return $summary;
+  }

Settings summary should simply return an array of strings, not a render array.

See FormatterInterface::settingsSummary().

In this patch:

1. Addressed both #98 and #103.
2. Re-exported views.view.language_test.yml

TODO: Fix test fails.
Looks like the new language field always gets the current language instead of the item's language at below $item:

+++ b/core/modules/views/src/Plugin/views/field/LanguageField.php
@@ -40,11 +45,9 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+    $languages = $this->options['native_language'] ? \Drupal::languageManager()->getNativeLanguages() : \Drupal::languageManager()->getLanguages();
+    return isset($languages[$value]) ? $languages[$value]->getName() : '';

Thanks @Gábor Hojtsy.
#110.1 - Just updated the if condition, so the summary gets same text.
#110.2 - Yep, rolled back changes I made to views in #108.
Fixed few test fails as per our discussion on IRC.

I'm trying to organize the "fix this field" issues and make sure there are issues for all of them, so making sure they're all listed on #2393339: [META] Make sure Views base fields are using Field API for formatting, and do not lose functionality as a start.

clearing viewData cache seem to fix the 4 fails...

So I'm a bit confused here about the rendering problem.

There are actually 2 language fields that Views is allowing us to add to views: the "original language" of the node (from the base node table) and "translation language" (from the node field data table).

If we're using Field UI rendering... can we actually get at both of these database fields? Is the problem that Field rendering says "Oh, you want a field called 'langcode'. I see that is on the node table, let's use that" rather than checking the field data table? Really it needs to figure out that in the View you have chosen either the one on node base or the one on the field data table, and get that data, rather than trying to know which one to choose.

I'm just kind of guessing here, based on what you said in #120, trying to understand what's happening.

Ah. So maybe we shouldn't use the basic 'field' handler for language fields then? We may just need to subclass that handler and do something different?

Yeah, it does seem like a special case.

I'm confused about what is working and what is not working here.

It seems like the only way around this is to make a special subclass of the Field views-field-handler-plugin class to handle the Language field(s), rather than trying to make the generic Field handler work.

I started looking into this, not done yet...

@Gabor:

I tried a few experiments without luck, I'm afraid this is telling us there's something wrong with our current model. Basically here we want to display the translation language, but there is no such field defined. Given that any piece of data attached to a (content) entity needs to be a field, we are basically missing a (translatable) field definition for the translation language.

Now, if we look at our API, we already have the translation language in the form of the ContentEntityInterface::language() method, and we have the default language via ContentEntityInterface::getUntranslated(). The concepts are there, but they are not backed by corresponding field definitions.

So what I tried to do (I'm not really done yet, wanted to get some feedback before coding too much), is going a pretty radical way and make our langcode definition translatable. If we look at our standard schema the {entity_field_data}.langcode is actually translatable, as we have a different value for each translation. The missing part is a default_langcode untranslatable field definition allowing us to tell which is the default translation.

After overcoming the initial shock, I realized this change seems to fit pretty well our current architecture: for instance this would allow us to have a language selector on content translation forms letting us change the translation language. This is not a big use case probably, but I think it clarifies pretty well that the direction should be correct.
Another example is that this way Rules would be able to distinguish between the various translation objects natively, by simply relying on field definitions, without needing to special case the translation language.

If you agree this is an approach worth trying we should open a separate issue and postpone this on that.

Btw, I tweeted about this at https://twitter.com/plach__/status/568937859844956161

Not sure I fully understand this yet.

This would essentially mean the field definitions would be the way the storage already is, and it wouldn't actually change the storage, correct? So less magic needed in the storage that makes the non-translatable langcode field actually stored per translation and the non-field default_language column.

Sounds like a change that makes sense, I've wondered before why it is not translatable, $node->getTranslation('de')->langcode->value isn't what you expect it is, as you said yourself.

Translatable vs. localizable, given we make the language field translatable, how does content_translation know that it is not actually a field that can be "translated" by the user? Or can it, in a way, based on your comment?

As TMGMT maintainer, I have yet another meaning of "translatable" to think about: The parts of an entity that I can extract and send to a translator, based on the tell that I sent you, my current code started picking up the content_translation_source field (with a value 'und') as a translatable text because it was translatable. But I think that can be solved by adding an options provider, which is also required for validation, @fago already opened an issue for that.

+1 on #141, makes a lot of sense IMO.
(if, by any chance, the refactor happened to also clean up the fact that ContentEntityBase internally stores the field values of the default language under 'und' rather that the actual langcode, I'd be double yay :-) But chances are this is an orthogonal refactor ?)

Regarding content_translation :
I have lost track a bit on whether BFD::setTranslatable(TRUE) means
"the field *is* translatable on all bundles, no config will ever change that"
or
"the field *supports* translatability, and content_translation UI can configure it to actually be translatable or not on a given bundle".

Because the latter doesn't sound like the behavior we'd want for that "translatable language field". If the entity type & bundle are configured to be translatable, I shouldn't be able to keep the "language" field untranslatable, that would be very broken.

Sounds good, created #2431329: Make (content) translation language available as a field definition and replied there. Marking this postponed again.

This would essentially mean the field definitions would be the way the storage already is, and it wouldn't actually change the storage, correct? So less magic needed in the storage that makes the non-translatable langcode field actually stored per translation and the non-field default_language column.

yeah, the change makes a lot of sense to me as well - so the field definitions really show you how things are stored. Clarity++. It's quite a bit of change for the meaning of $entity->langcode but given language() already works different, I think aligning them to work the same way makes it work as developers would expect it.

However, I do think I miss what it buys us here. A possibility to easily render the used display language?

Like fago, I'm still a confused about why we need to make langcode a translatable field.

It seems like what we need for this issue is

a) An entity-aware method to use as a Views formatter, which would print out the language of the translation being displayed, with the option to display the language name either in the defined Views display language for that row, or in the language's native language.

b) The same as (a) but to print out the original language of the entity.

The solution proposed currently in this issue is to use the generic Entity Field views formatter for these values, but this is not working because langcode is not currently a translatable field. So the proposal here is to make langcode be a translatable field.

It seems to me that an alternative solution would be to make two new formatters for "entity-aware translation language" and "entity-aware original language" that would use the existing language methods on ContentEntityInterface to discover what language to print, and then print it out. I don't understand why that wouldn't work?

We may have other reasons, as discussed above, for making langcode a translatable field, but it seems like the "make a non-generic formatter for Views" solution would be much easier, and would solve the problems of this issue?

Yes, technically formatters are independent. However, they are specified in the entity views data, not by users, so this isn't a problem.

So technically, you could put anything in for the plugin ID for a field handler in your entity views data, like assigning the custom 'node' formatter to be the formatter of the 'status' field on the User table. But you choose not to do that, because it wouldn't work if you did.

Similarly, we would choose to use the correct formatters in the entity views data for the language fields.

That is a point... As I see it, I think the reasons we need this issue are:

a) There are currently several custom language filters for specific entities, which have duplicated code, mostly so they can link to the entity and also hopefully display the language name in the native language (which is most likely not working).

b) Any entity without a custom language filter is using the base Views handler for non-entity-aware language fields. This is not correct, because:
- entity access is not checked
- it will just be displaying the language code from the database that is in the views query result, rather than the language of the translation that was selected for display for the entity via the Language settings of the view.

So the two proposals for solving this are:

1. Use the generic entity Field handler for all entity-related Language fields. But this will only work for the "language of this translation" field I think, and only if we also make the "language of this translation" field be a real, translatable field, which it isn't currently, and also if we make the "original language" be a real, non-translatable field, which it also isn't currently.

2. Make two specific Views handlers to handle the "language of this translation" and "original language" pseudo-non-fields. We might even be able to combine them into one handler with a setting to say whether to output the translation or original language, since the only thing that differs between the two cases is how to read this value from the $entity object.

I am not sure which of these is easier, but my guess is that (2) is easier, and also I think that (2)'s fix is more localized to solving the problem of dealing with language fields of entities in Views, while (1) is a more widespread fix. I think that both of them would solve the problem of this issue; we may have other reasons for wanting to do (1) but getting it actually done is, I'm pretty sure, going to be more work and have a lot of other implications on Drupal Core.

If we want to keep the current approach and avoid special-casing the (translation) language field, I don't see other solutions than making the langcode field translatable. I wouldn't mind if a different solution were adopted here, but I think this issue uncovered a flaw in our current architecture so I will work on #2431329: Make (content) translation language available as a field definition anyway.

#2431329: Make (content) translation language available as a field definition is in.

No need to start from scratch I'd say ;)

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/LanguageFormatter.php
@@ -22,22 +23,49 @@
-    // The 'language' cache context is not necessary, because what is printed
-    // here is the language's name in English, not in the language of the
-    // response.
...
-      $elements[$delta] = array('#markup' => $item->language ? String::checkPlain($item->language->getName()) : '');

Note that this was added because the docs for ::getName() say this:

  /**
   * Gets the name of the language.
   *
   * @return string
   *   The human-readable English name of the language.
   */
  public function getName();

So if that's wrong, the interface should be updated as well.

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/StringFormatter.php
@@ -144,4 +143,19 @@ public function viewElements(FieldItemListInterface $items) {
+  /**
+   * Generate the output appropriate for one field item.
+   *
+   * @param \Drupal\Core\Field\FieldItemInterface $item
+   *   One field item.
+   *
+   * @return string
+   *   The textual output generated.
+   */
+  protected function viewValue(FieldItemInterface $item) {

This is incapable of returning associated cache contexts & tags… which AFAICT means LanguageFormatter cannot actually extend StringFormatter and implement ::viewValue().
Alternatively, make this return a render array with #markup containing the string, then #cache[context] can be set as necessary. StringFormatter must then merge the cacheability metadata.

That will then allow you to resolve the language cache context @todo.

Setting the necessary cache contexts for the link (in case the link setting is enabled) will be taken care of in #2449459: [PP-1] Make URLs cache context aware — no work needs to be done for that here.

1. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/LanguageFormatter.php
   @@ -22,22 +23,47 @@
   -    // The 'language' cache context is not necessary, because what is printed
   -    // here is the language's name in English, not in the language of the
   -    // response.
   

   I wonder if we want to keep a comment like this, that uses the German/Deutsch example, explaining that you'd always see EITHER of those two strings depending on the field settings, and not a translation of it (such as "Allemand" in French or "Duits" in Dutch).

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/LanguageFormatter.php
   @@ -22,22 +23,47 @@
   +    $languages = $this->getSetting('native_language') ? \Drupal::languageManager()->getNativeLanguages() : \Drupal::languageManager()->getLanguages();
   

   Should or shouldn't we inject these?

3. +++ b/core/modules/language/language.module
   @@ -497,10 +497,10 @@ function language_field_info_alter(&$info) {
   +  if ($items && $operation == 'edit') {
   

   Wow, nice catch!

   I think this points at missing test coverage?

4. +++ b/core/modules/node/src/Tests/Views/NodeLanguageTest.php
   @@ -226,4 +227,55 @@ public function testLanguages() {
   +      $this->assertText('Français', 'French language shown translated.');
   +      $this->assertText('Español', 'Spanish language shown translated.');
   ...
   +      $this->assertNoText('Français', 'French language not shown translated.');
   +      $this->assertNoText('Español', 'Spanish language not shown translated.');
   

   s/translated/in native form/

5. +++ b/core/modules/node/tests/modules/node_test_views/node_test_views.views.inc
   @@ -0,0 +1,16 @@
   +  if (Drupal::state()->get('node_test_views.use_basic_handler')) {
   

   Missing leading backslash.

Only nits and nitty nits. Patch looks good, but I can't really sign off on the Views stuff, so keeping at NR.

1. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/LanguageFormatter.php
   @@ -26,6 +29,58 @@
   +   * Constructs a StringFormatter instance.
   

   LanguageFormatter :)

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/LanguageFormatter.php
   @@ -8,8 +8,12 @@
   +use Symfony\Component\DependencyInjection\ContainerInterface;
   +use Drupal\Core\Language\LanguageManagerInterface;
   

   Nit: we usually sort these alphabetically.

3. +++ b/core/modules/node/src/Tests/Views/NodeLanguageTest.php
   @@ -226,4 +227,55 @@ public function testLanguages() {
   +   * Assert the presence of language names in their English or native forms.
   

   Nit: Asserts.

+++ b/core/modules/node/tests/modules/node_test_views/node_test_views.views.inc
@@ -0,0 +1,16 @@
+ * Implements hook_views_data_alter().
+ */
+function node_test_views_views_data_alter(array &$data) {
+  // Make node language use the basic field handler if requested.
+  if (\Drupal::state()->get('node_test_views.use_basic_handler')) {
+    $data['node_field_data']['langcode']['field']['id'] = 'language';
+  }

+++ b/core/modules/views/src/EntityViewsData.php
@@ -318,7 +318,7 @@ protected function mapSingleFieldViewsData($table, $field_name, $field_type, $co
-        $views_field['field']['id'] = 'language';
+        $views_field['field']['id'] = 'field';
         $views_field['argument']['id'] = 'language';

Do we still need the toggle?

Ah, this makes sense.

This looks perfect for me.

Nice patch. This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 8d87a92 and pushed to 8.0.x. Thanks!