Entity Links fields does not have translation support

Any solution for this Issue in 8.4.2 drupal version:

Fix and a test.

Adding related/duplicate issues. Technically #2447821: Translated nodes in content views are all linking to the current language is the oldest so that should be the one to work on, but the issue summary here is more complete, so started work here.

Changed so 'hreflang' is only added in multilingual sites which matches the current situation in HEAD.

And the new tests didn't handle being in a subdir well, so lets see if this makes that better.

I just tested #9 and with that patch the "Link to Content" field now returns the correct URL for my translated nodes as well as my source nodes. I checked hreflangs too, but those are unchanged and still working fine (i.e. 'only added in multilingual sites which matches the current situation in HEAD.'). The patch actually doesn't seem to involve hreflang at all (?).

@caspervoogt thanks for the manual testing!

The hreflang gets set when you pass a language to the url build. Currently, this doesn't happen. With the patch in #5, this ALWAYS happend, even with non-multilingual sites it would set hreflang="en", see the test fail in the comment test in #5.

So to make this change less disruptive for existing sites, I decided to take that out and only set this when it is relevant, so only when we are dealing with a multilingual site. If we feel this should always be set (is it relevant for usability or SEO?), then we should update the comment test and go for the change in #5.

Bumping this to major since this broke certain configurations in 8.5.0 because of the lack of a workaround when 'Content: path' field got deprecated.

Bit of a clean up. Dedicated test view now and testing for the edit and delete links too.

@Lendude

I applied the patch to my installation and Drupal, and I figured out that: when the "Output the URL as text" is activated, we get the non-translated link, but if we are not activating it it's fine.

We were using this option with the "path" field. Any chance it could work with the "view_node" ?

@arakwar thanks for the manual tests! Silly me, thinking that would just work.

This fixes the output for 'output url as text', plus a test for it.

Thanks for catching that, arawak. I was about to mention that issue myself (just ran into it), and patch 15 solves that for me (thanks Lendude!).

@caspervoogt do you feel up to doing a full review so maybe we can move this to RTBC?

I just reviewed on my end. I had not previously tested the Edit Content link; those work for me. As a test I had a look at my /admin/content view, which does not filter on language and shows nodes of both French and English. My French nodes get French edit links in the /admin/content view I'm using, whether I am viewing the view in English or French (e.g. /fr/admin/content vs /admin/content), so that's good. I then tested on a custom view, which does filter on language, and the Edit Content links are fine there also.

I also checked the Operations field and there the edit link is also correctly translated to the French alias.

Next I checked the View Content link, which showed the correct translated alias whether for French or English.

Lastly I tested using rewrites in a custom text field, placing {{ view_node }} and {{ edit_node }} in there, and those presented no issues. I also tested adding such rewrites on the Link to Content and Edit Content fields themselves, and also found no issues.

So from a functionality perspective I think it's RTBC for sure.

Regarding johndevman's note about EntityManagerInterface being deprecated, that is going to be removed before D9 so it would be good to replace with something else. Out of the files affected by this patch, only core/modules/views/src/Plugin/views/field/LinkBase.php references this. I have attached a patch that takes care of that. Tested and working for me on 8.5.x-dev but should be ok on 8.6.x-dev too.

Thanks for the reviews! @caspervoogt that looks like the interdiff in #19

Took the patch from #15 and applied the changes in #19 and did some more doc block updates.

The reason I took the deprecated EntityManager is because this is type hinted in the EntityTranslationRenderTrait. But if it works with using the EntityTypeManager that's much better.

Stray tab snuck in.

• I am linking to a node without language set
• using "Output the URL as text"
• and want the link to go to the Rendering language set in the view.

,
With #22 it goes to something like '/node/123', not to '/de/node/123' (or the url alias without language prefix).

So instead of the translated entity's language

$this->getEntityTranslation($entity, $row)->language()

I propose somehting like

$langcode = $this->getEntityTranslationRenderer()->getLangcode($row);
$this->languageManager->getLanguage($langcode)

I wasn't able to create a interdiff (interdiff got "The next patch would create the file /tmp/interdiff-1.tpymsL"), so I just attached the full patch.
And I don't know how to add a test for "Output the URL as text" ...

Btw: I found an old, unresolved issue 2667086 with a similiar patch in comment #17.

@gngn thanks for looking at this and finding the other issue.

I'm going to roll this back to the version in #22. The use case in #23 doesn't feel like a bug, but just as a certain way some sites might want to handle this, in most cases I think the link to '/node/123' would be fine.
I don't want this to side track the effort of first getting this bug fixed, after that we can look at the use case in #23 in a follow up.

Sounds like a plan Lendude.

index 75b8da3949..f7b2877a6c 100644
--- a/core/modules/views/src/Plugin/views/field/EntityLink.php

--- a/core/modules/views/src/Plugin/views/field/EntityLink.php
+++ b/core/modules/views/src/Plugin/views/field/EntityLink.php

+++ b/core/modules/views/src/Plugin/views/field/EntityLink.php
@@ -36,7 +36,11 @@ protected function renderLink(ResultRow $row) {

@@ -36,7 +36,11 @@ protected function renderLink(ResultRow $row) {
    */
   protected function getUrlInfo(ResultRow $row) {
     $template = $this->getEntityLinkTemplate();
-    return $this->getEntity($row)->toUrl($template)->setAbsolute($this->options['absolute']);
+    $entity = $this->getEntity($row);
+    if ($this->languageManager->isMultilingual()) {
+      $entity = $this->getEntityTranslation($entity, $row);
+    }
+    return $entity->toUrl($template)->setAbsolute($this->options['absolute']);
   }
 
   /**

Do we need to adapt \Drupal\comment\Plugin\views\field\EntityLink too?

@Lendude: Thank you for the feeback - but I do not agree - why is '/node/123' better than '/node/123'?
I thought the issue is about "language correct" links?

Ignoring the Rendering language from the view - that might be another issue.
But I think if a user selects something as Rendering language in the view configuration that we should use this setting.

Or am I getting something wrong?

In #23's case, I can see the logic in not including that in this RTBC at least;

The node has no language set yet the view is configured to display the rendering language of the view. But the node has no language... therefore we don't use a language alias in its path.

Speaking just for myself here: on most of the multilingual sites I deal with, there are very few (usually no) nodes with language undefined and whenever I do have that, I never want such nodes to include a language prefix. Normally I don't use a language prefix for the primary language on such a site, so that if a view were to return a link to a language-undefined node using the language of the views row, it would return a incorrect path, e.g. /en/node/123 even though my English nodes are not supposed to have language prefixes and that node has no language defined to begin with.

Do we need to adapt \Drupal\comment\Plugin\views\field\EntityLink too?

Probably, but since that doesn't extend LinkBase lets not do that here, but do so in a follow up.

Added the proposed follow ups to the IS.

@caspervoogt (#28) My experiences with undefined language nodes are quite different - also speaking just for myself here:

• Most of my sites are multi language
• I have quite a few nodes with language undefined (cannot force my customers to always translate their content)
• and when I do have that, I always want such nodes to include a language prefix

That is the way my customers want it...

This is quite critical for all multilingual sites being highly based on views.(read more Button)
Is there a quickfix for the link to content field available that also works in rewritten fields via placeholder?

@patrickroma did you try the patch in #24? The best way to get this into core is if people review the patch and provide feedback, that way we won't need a quickfix....

Hi all,

#24 work for me !

Thanks :-)

#24 is working well for me.

#24 is working also for me.

#24 works for me as well, thank you!

#24 tested and works for me.

#24 tested and works for me too.

#24 fixed the problem for us

@johndevman thanks for taking a look at this, and thanks everybody for reporting back that it's working in the field.

Fixed nits. Moving to 8.5.x since this is a bug fix.

I confirm that patch #42 works in 8.5.3.
Tested with "Link to content" in Views.

Very nice! :)

Confirming that patch #42 resolved my use case problem (on 8.5.4), wherein "link to content" links within a view were disregarding the language of the content in question (even though the teaser was otherwise displayed in the correct language).

Changing status to RTBC given that a number of people have reported this as working over the past few weeks, and the latest patch revision made only minor naming changes.

Link to content works. But if you rewrite the output and use the field value as placeholder token {{ path }} translation seems to be ignored. Anyone else having this issue?

@patrickroma when I use the 'Link to content' field I have no {{ path }} token available in my list of 'REPLACEMENT PATTERNS', just '{{ view_node }} == Link to Content', which seems to work fine when I use it as a replacement token for something else, in this case the body field:

The {{ path }} token sounds like a leftover from the old Node path field that was deprecated in 8.5.0. Have you tried replacing it with {{ view_node }} ?

If I'm just missing some steps to reproduce the issue, please provide them.

If this is something that gets broken by applying this patch, please set this back to needs work. If it something that is currently not working and after applying this patch is still not working please consider opening a follow up issue so we address the main issue first.

Setting back to RTBC.

@timomueller thanks for the update.

I think the most important question now is, can you reproduce this in a clean install or just in your fully configured site? And if you can reproduce this in a fresh install, do you have some steps to reproduce?

If not, I'm thinking your view might still be using the old node_path plugin. Do you have a yml export of the config file for this view? Could you check which plugin_id it's using? Or share the export here?

@timomueller hmm it's using the right plugin, really stumped as to why it would show the {{ path }} token still.

• Does it help if you remove the language filter in any way? Won't fix the {{ path }} token showing up but might get you the right links in it.
• Does it help if you just rebuild this View from scratch? No duplicating, just click it together again. Or just a very minimal version of it.

As to fixing this, the question still remains: can you reproduce this on a clean Drupal install? Because I'm not having any luck with that. And if we can't get this to break in vanilla core, there is not much we can fix here. Then it might be contrib code or custom code getting in the way.

@timomueller perfect! Thanks for digging into this!

Back to RTBC I'd say.

I faced another issue that when content language is Not specified or Not applicable and I have two languages when click link in the second language it's switch interface to the default language.
Suggested solution:
I updated @Lendude patch and I add simple check by Entity language id if it's equal Not specified or Not applicable it will add current interface language to link to prevent switching between languages interfaces.
Here's the updated patch.
Thanks

Sorry just correct patch name.

@mahmoud-zayed I'm still not convinced this is needed in a bug fix. I don't think that redirecting to the default language is any worse then redirecting to the current UI language. It's just an implementational choice.

If it turns out, this is the right way of doing this, we would need a test for this. Currently the added code doesn't have test coverage, and it should have.

+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
@@ -178,9 +207,15 @@ protected function renderLink(ResultRow $row) {
+        // Language equal Interface language to prevent switching between languages interfaces.

Also, this is over 80 characters long and should probably read something like "When the entity language is set to 'Not specified' or 'Not applicable' we set it to the current active language to prevent unnecessary language switching."

@Lendude I'm currently working on a multilingual site where the language of almost all content types is set to Not applicable. In other words, the multilingual support required on the site is all about the UI. So I would consider redirecting to the default language and suddenly changing the interface language a bug rather than just an implementational choice.

I have been testing the patch, and it seems to work with link fields. However, I found that the same problem exists with links in other types of fields such as linked title field and dropbutton field.

As this issue is about link fields, should separate issues be opened for different field types with the same problem or should the issue title and description be amended to cover the same basic problem with all views fields that contain links?

It looks like the problem with Dropbutton is that Links::getLinks() just uses ['alter']['url'] and does not take ['alter']['language'] into account.

I'd be happy to have a go at a patch to make Dropbutton work, but I can think of several ways to fix this, and am not familiar with the code, so am not sure what is the best approach:

1) Add support for ['alter']['language'] to Links::getLinks().

2) Use FieldPluginBase::renderAsLink() in Links::getLinks() (not so sure about this one, don't know about possible side effects).

3) In LinkBase::addLangcode() also change the language option in ['alter']['url']. This could be done in the current scope of this issue, but perhaps the original value should be left as is?

4) Something else?

@aleksip please look at the other plugins in new issues, this fix is hard enough to land without the additional scope.

@Lendude Yes, I have learned that it can be very hard and take a very very very long time to land anything in core. :)

While it would be great to get this fix in, especially as it is very close to being committed(?), maybe a common solution in FieldPluginBase would ultimately be the best, as it is reasonable to expect the same behaviour from all views fields? Or would that not be feasible for some reason?

Added another related issue: #2862511: Link to Entity get invalid language link in views..

In case anyone reading/following this issue might be interested, I have now opened two new issues with proposed fixes for Dropbutton and linked entity fields (e.g. title, when content language is 'Not specified' or 'Not applicable'):

• #2991408: Dropbutton fields do not have translation support
• #2991440: Links to entities with language set to 'Not specified' or 'Not applicable' should default to current UI language

If you do not want to use patches, you have a work around in D8 and views, by using twig.
1. add ID as field and exclude from display
2. create a custom text field and add the following into that:

<a href="{{ path('entity.node.canonical', {'node': nid}) }}">Read on</a>

3. if you want to use the translated link to wrap around an image for example. You can use a custom text field and paste the above twig into it (without the a-tag).
4. use the {{nothing}} replacement variable as url when rewriting your image_field

That works for me.

The #57 patch work for me.

#66 works well!
I wait the final patch, thanks.

#66 works temporarily for me.

The patch for #42 works well for us as well.

What are the plans for this? Could we get it committed (since it has tests etc) and open #56 as a follow up issue?

[edit] with #66 and more than one views display, the view goes crash.

After 8.6.1 core update the #57 patch don't work.

The view display only in english in every languages.

I hope this bug will be solved quickly because it's very bad.

I used the title with a classe for hide the text for the moment because the title of the node is not impacted by this bug...

wrong typo sorry

hi all,
here is how i solved this problem

i have a custom entity called toile, fully translated
a view named gallery, overview of these entities, displayed as a grid, each item containing a link pointing to the entity

the problem was as described that whatever was the translation selected of that view, every link was pointing to the default langage entity... bad :-(

fortunately it can be solved using this method:

1- Add the Entity translation language field, in the fields of your view. note that it have to be below the link field, so you can use the link as a token:

2- Change the link field:

exclude from display
render URL as text (that way the pointing URL can be used as a token in URL rewriting...

3- Then we have to change the settings for the new Entity translation language field that way:

rewrite the field as a custom link using the available tokens below: {{ langcode__value }}{{ view_toile }} in my case
render the field as a custom text (as otherwise the URL should really look ugly as a link... {{ 'Zoom' }} in my case, helpful as it only has to be translated in russian ;-)

4- And finally you can add your view translations, and change the translated text displayed for the link in all your languages if you have to...

In my case it totally solved the problem, i am using 8.6.2 core
hope it was clear and helpful
cheers

Tested #57 on 8.5.8 and it solved the issue.

I can confirm, patch 57 worked for me, Drupal version 8.6.3

Patch #57 solves issue (tested on core 8.6.3) for me too.

Patch #57 worked to solve the same issue with a "link to content" field (core 8.6.4)
Thanks

Can confirm patch from #57 fixes the problem on a link to content field for me too (core 8.6.3). Couldn't find any problems caused by the patch so far.

Thanks for the great work!

Apparently we need a change record. Also @Lendude, views maintainer, says in #58 that the latest patch contains an additional fix that is probably not needed. And if it is we need further test coverage. I think we should open a follow-up and go back to the fix in #42.

Also @mahmoud-zayed generally we try to avoid rtbcing patches we've contributed to.

Is the issue described in "Links to entities with language set to 'Not specified' or 'Not applicable' should default to current UI language" the same as #56 or do we need another follow up?

Thank @alexpott for taking a look at this and your feedback.

Re-upping #42

#2991440: Links to entities with language set to 'Not specified' or 'Not applicable' should default to current UI language seems like a good follow up.

Will add a CR for the change to the LinkBase constructor.

Added CR : https://www.drupal.org/node/3023427

#43, #44, #54 and #70 confirm the patch in #42 . We've also been using the patch in production for a few months now. Setting to RTBC.

1. +++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
   @@ -43,10 +61,16 @@
   -  public function __construct(array $configuration, $plugin_id, $plugin_definition, AccessManagerInterface $access_manager) {
   +  public function __construct(array $configuration, $plugin_id, $plugin_definition, AccessManagerInterface $access_manager, EntityTypeManagerInterface $entity_type_manager, LanguageManagerInterface $language_manager) {
        parent::__construct($configuration, $plugin_id, $plugin_definition);
        $this->accessManager = $access_manager;
   +    $this->entityTypeManager = $entity_type_manager;
   +    $this->languageManager = $language_manager;
   

   As this is a base class we need to dance the optional / @trigger_error dance. So anything in contrib / custom that extends this does not break.

   Something like this:

     public function __construct(array $configuration, $plugin_id, $plugin_definition, AccessManagerInterface $access_manager, EntityTypeManagerInterface $entity_type_manager, LanguageManagerInterface $language_manager = NULL) {
       parent::__construct($configuration, $plugin_id, $plugin_definition);
       $this->accessManager = $access_manager;
       $this->entityTypeManager = $entity_type_manager;
       if (!$language_manager) {
         @trigger_error('@todo', E_USER_DEPRECATED);
         $language_manager = \Drupal::service('language_manager');
       }
       $this->languageManager = $language_manager;
     }
   

2. +++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
   @@ -194,4 +222,35 @@ protected function getDefaultLabel() {
   +  /**
   +   * Returns the entity type manager.
   +   *
   +   * @return \Drupal\Core\Entity\EntityTypeManagerInterface
   +   *   The entity manager.
   +   */
   +  protected function getEntityManager() {
   +    return $this->entityTypeManager;
   +  }
   

   This feels wrong. The trait uses methods on both EntityTypeManagerInterface and EntityRepositoryInterface - we need to provide the entity manager here :( until there is a version of EntityTranslationRenderTrait that works with the correct services.

   So I think we need to inject the entity manager here.

@alexpott thanks for the feedback.

#87.1 done, not sure about the wording, quick search didn't turn up anything like this is core yet
#87.2

+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
@@ -57,7 +81,9 @@ public static function create(ContainerInterface $container, array $configuratio
+      $container->get('entity.manager'),

turns out we were already passing the entity manager service, oops! so just updated the docblocks and uses

Patch from #88 seems to work fine on Drupal 8.6.4.

I can confirm patch #88 works on Drupal 8.6.7

Unfortunately #88 is not working on 8.6.10

@isinadinos, I got it applied. Here what I got with 8.6.10 with composer -v :

Found 1 patches for drupal/core.
  - Updating drupal/core (8.6.7 => 8.6.10): Downloading (100%)
  - Applying patches for drupal/core
    patches/2877994-88.patch (Entity Links fields does not have translation support)
patch '-p1' --no-backup-if-mismatch -d 'web/core' < '/var/www/html/patches/2877994-88.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/views/src/Plugin/views/field/EntityLink.php b/core/modules/views/src/Plugin/views/field/EntityLink.php
|index 75b8da3949..f7b2877a6c 100644
|--- a/core/modules/views/src/Plugin/views/field/EntityLink.php
|+++ b/core/modules/views/src/Plugin/views/field/EntityLink.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored
can't find file to patch at input line 22
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/views/src/Plugin/views/field/LinkBase.php b/core/modules/views/src/Plugin/views/field/LinkBase.php
|index 31dca4c7c3..c429c99aeb 100644
|--- a/core/modules/views/src/Plugin/views/field/LinkBase.php
|+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

8 out of 8 hunks ignored

patching file core/modules/views/tests/modules/views_test_config/test_views/views.view.test_link_base_links.yml

patching file core/modules/views/tests/src/Functional/Handler/FieldEntityLinkBaseTest.php

patch '-p0' --no-backup-if-mismatch -d 'web/core' < '/var/www/html/patches/2877994-88.patch'
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/views/src/Plugin/views/field/EntityLink.php b/core/modules/views/src/Plugin/views/field/EntityLink.php
|index 75b8da3949..f7b2877a6c 100644
|--- a/core/modules/views/src/Plugin/views/field/EntityLink.php
|+++ b/core/modules/views/src/Plugin/views/field/EntityLink.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

1 out of 1 hunk ignored
can't find file to patch at input line 22
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/views/src/Plugin/views/field/LinkBase.php b/core/modules/views/src/Plugin/views/field/LinkBase.php
|index 31dca4c7c3..c429c99aeb 100644
|--- a/core/modules/views/src/Plugin/views/field/LinkBase.php
|+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.

8 out of 8 hunks ignored

patching file b/core/modules/views/tests/modules/views_test_config/test_views/views.view.test_link_base_links.yml

patching file b/core/modules/views/tests/src/Functional/Handler/FieldEntityLinkBaseTest.php

patch '-p2' --no-backup-if-mismatch -d 'web/core' < '/var/www/html/patches/2877994-88.patch'
patching file modules/views/src/Plugin/views/field/EntityLink.php
patching file modules/views/src/Plugin/views/field/LinkBase.php

patching file modules/views/tests/modules/views_test_config/test_views/views.view.test_link_base_links.yml

patching file modules/views/tests/src/Functional/Handler/FieldEntityLinkBaseTest.php

#88 works for me in drupal 8.6.10
Applied with:
patch -p1 < path/file.patch

This is failing because of #3023981: Add @trigger_error() to deprecated EntityManager->EntityRepository methods on 8.7.x, this needs to be updated to use the EntityTypeManager, not the EntityManager. So basically we can now address #87.2

This addresses #95/#87.2, should be back to green.

Duh...

With #88: everything is fine
With #98: I get the following error when browsing to a view:
Fatal error: Class Drupal\views\Plugin\views\field\EntityLink contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Drupal\views\Plugin\views\field\LinkBase::getEntityManager) in .../drupal8/core/modules/views/src/Plugin/views/field/EntityLink.php on line 15

@DuneBL that is probably on 8.6.x ? The patch in #98 is 8.7.x only since the dependant changes were only done in 8.7.x in #3023981: Add @trigger_error() to deprecated EntityManager->EntityRepository methods

@Lendude sorry for disturbing... you are right, I overlooked the 8.7 spec

The #57 patch worked for me. Thanks mahmoud-zayed.

Hi, I attempted the following patches: #57, #84, #88 and #98 with limited success. For #57, #84 and #88, it generated the link correctly but when you clicked on it I got the one line of death saying the Website encountered an error.

For #98 I received the following error.
Fatal error: Class Drupal\views\Plugin\views\field\EntityLink contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Drupal\views\Plugin\views\field\LinkBase::getEntityManager) in (localhost)\web\core\modules\views\src\Plugin\views\field\EntityLink.php on line 15

Temporarily I can use <a href="{{ path('entity.node.canonical', {'node': nid}) }}">TESTING</a> for my needs, but I have a site with English and four other languages. We have multiple views that will need to use an entity_link along with other sites in the future that will probably have the same set-up and need. My Drupal version is 8.6.10, all security updates have been implemented as well.

I'm not sure what other information to provide so if there is anything you need please let me know. The temp code above will work for now, but we'd like to soon after a solution that is more viable in the long-term. Any help would be appreciated.

Thanks.

@jess_m the patch in #98 is for 8.7.x only, not sure why #88 wouldn't work for you on 8.6.10, but if you get a white screen after clicking the link, that is not the fault of the link, so probably something unrelated to this.

@Lendude

I think what happened was that #88 was my third patch to try and one of the other patches caused a problem so when I tried #88 it showed up as an error. I wiped out my site as it was then and pulled in a fresh copy of it from scratch, applied the patch and it now works. Thanks!

Jess

#88 works as advertised. Thank you!

#57 works for us (Drupal core 8.5.14). Thank you!

#88 solved my issue

So we have a fair number of 'Tested By the Community' instances, anybody feel up to putting the R in front of that and setting this to RTBC?

I can also confirm that #88 solved the issue for us, on core 8.6.14. Thanks!

1. Tested manually on 8.8.x-dev.
2. New patch with minor changes in the docs, removal of unnecessary use statement.
3. #111 left unchanged so needs review by the commit.

After applay Patch

Class Drupal\views\Plugin\views\field\EntityLink contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Drupal\views\Plugin\views\field\LinkBase::getEntityManager) in C:\wamp\www\colibri.local\web\core\modules\views\src\Plugin\views\field\EntityLink.php on line 15

@Regnoy see a bunch of previous comments, you probably applied the latest patch to 8.6.x, use the patch in #88 for 8.6.x

Note that "Link to the Content" is still not working (see #2447821).

Using the "Link to content" field as a replacement for the URL of the title field.

This doesn't seem to work (bottom left of attached screenshot - hovering over the "Chinese" title link).

Is there some processing happening when "Output this field as a custom link" is checked that strips the language?

1. Tested manually on 8.8.x-dev. +1 RTBC.
Back to "Needs review" due to changes in tests.

2. #111 left unchanged so needs review by the commit.

3. The 'test_link_base_links' tests also 'Link to Content'. Needs follow-up if the "Link to content" field not work as a replacement for the URL of the title field.

#111 is not a problem, this is a bug fix so it should target 8.7.x

Test coverage changes look fine, back to RTBC

Patch #88 fixes our issue on 8.6.15
I tried the newer patch #118 on 8.6.15 and it crashed on 8.6.15 (even though it applied cleanly on my build). I haven't tested patch 118 on 8.8.x , only testing on 8.6.15

Patch #88 works for us on 8.6.15 thanks!

Seems like an important fix should get attention soon would have saved me a day of work, help save others time as well.

Merci!

This should go in right away!

Several other patches are waiting but this one is ready now!

Patch from #88 still working well with 8.7.1.

I'd really love to see this merged soon. Been applying the patch for months again and again.

To the core maintainers, If you are not running a site with more than one language then please assign this issue to a core maintainer that does.

Patch for 8.7.x works as well on the new 8.7.1 release.
Please commit, has tests too. Great work on this!

Tested patch #98 now on 8.7.1, also works without any problems so far.

Unrelated fail

Confirming RTBC for #118 and importance of this issue! This should definitely be part of the next core release. Very essential fix when using multilanguage.

I tested #118 also manually plus tests... and everything is fine.

Unrelated fail

***EDIT*** impatience

@joseph.olstad Multilingual sites need this fix. Please commit it or start recruiting new 'views' core maintainers.

In what way @joseph.olstad was that a helpful comment? In what way are you making this issue moving forward with that comment? In what way have you read the code of conduct?

@joseph.olstad how can you be on drupal.org for 8 years and:

• Not even consider applying the patch to your project while waiting for it to be committed to core.
• Be completely oblivious to the fact that core (and contrib!) maintainers put in a lot of their time for free for the benefit of others
• Post 4 comments on this thread, 3 of which being completely unhelpful stating nothing more than "I need this now11!!oneone"

Very unprofessional dude. There's a lot of things you can learn from people like Lendude. Politeness being one of them.

To end on a positive note: The patch looks great (at a glance), job well done all!

+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
@@ -194,4 +247,39 @@ protected function getDefaultLabel() {
+  public function getEntityTypeId() {

I realise this is public in the parent trait - but why? The only call I can see is from \Drupal\views\Entity\Render\EntityTranslationRenderTrait::getEntityTranslationRenderer so I think it possible should have been protected, as its API surface we don't need. Should we make the new implementation added in this patch protected (PHP allows that) so we don't add anymore API surface and then create a follow up to investigate the impact of making the other implementations protected - although I suspect that would be an API change for anything that wasn't marked internal. I've asked the same question in #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage where it was introduced.

Also, I can't speak for other maintainers, but I look at the RTBC queue in reverse chronological order, i.e the issues that were recently updated are at the bottom of the list and the ones that have been RTBC without comment for longer are at the top. So it may be that the regular comments that don't add anything new actually keep dropping this to the bottom of that sort, meaning it doesn't get attention.

@larowlan That was a very noteworthy point in #137, thanks! I added it to the Getting an issue addressed sooner (and issue queue etiquette) page.

@larowlan makes a great point in #136 - it's what has made me think twice when looking at this patch before. See https://www.php.net/manual/en/language.oop5.traits.php#language.oop5.tra... for how to change method visibility.

ok if I understood 136 #2877994-136: Entity Links fields does not have translation support correctly, change from public to protected

The added tests will ensure that we won't regress this in the future. Many people do not have the required skill (or time) to find and apply this fix.
Same patch fixes 8.7.x and 8.8.x branches
If you want I can reroll the fix for 8.6.x as well?

RTBC +1

Fixes we got from 88 and 118 are still fixed using 140.

RTBC +1

RTBC +1

RTBC +1

RTBC +1

Crediting @aleksip, @johndevman, @alexpott, @larowlan for reviews.

Crediting @paper boy, @patrickroma, @Bessonweb, @tibbsa, @ConradFlashback, @DuneBL, @jess_m, @arakwar for trying out the patch, testing and reporting back.

Note I've not crediting people for the numerous +1s to the patch - though thanks for all the reports it is great to know so many people have tried and need this fix.

Committed 3839c0d and pushed to 8.8.x. Thanks!

I think given the number of people applying the patch we should consider backporting to 8.7.x BUT I think a release manager should chime in because we're changing the constructor to a base class.

Thank you @Alexpott!

Can you please cherry-pick this for 8.7.x as well? **EDIT** ok I see the comment about framework manager review. **EDIT**

git fetch;
git checkout 8.7.x;
git cherry-pick 3839c0d;

clean cherry-pick
no conflicts (test results above).

+++ b/core/modules/views/src/Plugin/views/field/LinkBase.php
@@ -43,10 +69,32 @@
     $this->accessManager = $access_manager;
+    if (!$entity_type_manager) {
+      @trigger_error('Passing the entity type manager service to \Drupal\views\Plugin\views\field\LinkBase::__construct is required since 8.7.0, see https://www.drupal.org/node/3023427.', E_USER_DEPRECATED);
+      $entity_type_manager = \Drupal::service('entity_type.manager');
+    }
+    $this->entityTypeManager = $entity_type_manager;
+    if (!$entity_repository) {
+      @trigger_error('Passing the entity repository service to \Drupal\views\Plugin\views\field\LinkBase::__construct is required since 8.7.0, see https://www.drupal.org/node/3023427.', E_USER_DEPRECATED);
+      $entity_repository = \Drupal::service('entity.repository');
+    }
+    $this->entityRepository = $entity_repository;
+
+    if (!$language_manager) {
+      @trigger_error('Passing the language manager service to \Drupal\views\Plugin\views\field\LinkBase::__construct is required since 8.7.0, see https://www.drupal.org/node/3023427.', E_USER_DEPRECATED);
+      $language_manager = \Drupal::service('language_manager');
+    }
+    $this->languageManager = $language_manager;
   }

I'm not keen on backporting the changes to a base class constructor to a patch release, maybe for a fatal error or data loss, but this is neither. Has anyone grepped contrib to check if there would be modules affected?

If requiring entity_type.manager was causing problems in contrib we'd have known by now in other projects using entity_type.manager.

as for grepping contrib, contrib isn't views, views is in core, contrib just passes things in and expects output.

Garbage in, garbage out.

As an annecdote, we're currently using the code that was pushed into 8.8.x in 8.7.x (using the patch) with over 300 contrib modules, no issues.

What this patch does:

simple view with links and node fields
display fields:
linked title field to node title
taxonomy term label

filter by node type "article"
filter by current display language

OR rss feed
linked to node content title
taxonomy term label

filter by current display language

Before fixing with patch:
site default language: english
english URL in path: https://mybrokensite.com/en/viewpage

display row:
<a href="https://mybrokensite.com/en/article-title-in-english">Article title in english</a> example taxonomy term english.

english is correct, displays english title, english taxonomy term label and english link to content /en/node/1234 or url alias path if exists.

site default language: english
french URL in path: https://mybrokensite.com/fr/viewpage
display row:
<a href="https://mybrokensite.com/en/article-title-in-english">Titre en français sacre bleue</a> étiquette de taxonomie français.

Our use case was an rss feed.

AFTER PATCHING with fix:

site default language: english
french URL in path: https://myfixedsite.com/fr/viewpage
display row:
<a href="https://myfixedsite.com/fr/titre-en-francais-sacre-bleue">Titre en français sacre bleue</a> étiquette de taxonomie français.

as for grepping contrib, contrib isn't views, views is in core, contrib just passes things in and expects output.

It's a base class, which means contrib and custom code can extend it, potentially overriding the constructor.

Is there a way to download ALL contrib modules, like a master list of uri to the git repos for all projects on drupal.org?
If there was, I would write a script and download ALL of contrib and do a grep for this base class.

Maybe I would have to write a crawler for drupal.org and crawl all 3+million nodes, look for project pages out of those and add the git repo link for each project that has an 8.x version?

Or is there an easier way? I could write a crawler to do this but hate to write code for nothing if this is already listed somewhere or if someone has a better idea?

>Or is there an easier way?

Looks like http://grep.xnddx.ru/ can do it.

http://grep.xnddx.ru/search?text=LinkBase is the site we regularly use to grep for contrib, it has a lot of contrib covered. The following relevant results were found:

Directly extending LinkBase without constructor override (I did not go further (ie. did not look at classes extending these classes)):

• rng-8.x-1.0/src/Plugin/views/field/LinkRegister.php
• entity_gallery-8.x-1.x/src/Plugin/views/field/RevisionLink.php
• box-8.x-1.x/src/Plugin/views/field/RevisionLink.php
• moderation_note-8.x-1.x/src/Plugin/views/field/ModerationNoteLink.php
• views_custom_link-8.x-1.0/src/Plugin/views/field/CustomViewsLink.php
• support-8.x-1.x/modules/support_ticket/src/Plugin/views/field/RevisionLink.php

These are abstract classes themselves, but none of their extensions seem to override the constructor:

• simple_modal_entity_form-8.x-1.x/src/Plugin/views/field/ModalEntityOperationBase.php (abstract class!)
• entity_generic-8.x-1.x/src/Plugin/views/field/GenericOperationModalBase.php (abstract class!)

Overrides constructor with further arguments, so people using at least these modules would get WSOD if the patch is merged to 8.7.x:

• scheduled_transitions-8.x-1.x/src/Plugin/views/field/ScheduledTransitionRevisionLinkField.php
• entity_print-8.x-1.x/modules/entity_print_views/src/Plugin/views/field/PrintLink.php
• cloud-8.x-1.x/src/Plugin/views/field/ServerTemplateListLink.php
• cloud-8.x-1.x/src/Plugin/views/field/CloudPricingInternalLink.php
• cloud-8.x-1.x/src/Plugin/views/field/CloudInstanceListLink.php

> Overrides constructor with further arguments, so people using at least these modules would get WSOD if the patch is merged to 8.7.x:

Well, no, because we make the arguments optional with BC? There are still possibilities that something breaks, but they have been very rare since we started to be more strict about constructor changes and provide BC.

Not saying that this should or should not be backported, just that this statement isn't true. And there's also always custom code to think about, BC isn't just about the known contrib code, if anything, it gives us an idea about how widespread those cases might be :)

If I am understanding #167 and #168 correctly, it appears that there is little to no risk that this change would break contrib.

The only breakage that I could see would be unsupported breakage for workarounds to this unexpected behavior, example might be twig extensions that developers have made on their own >IF< they weren't fortunate enough to find this patch I could see people might have written their own twig extensions to override the core behavior (prior to this patch or without this patch).

I recall when looking for a solution to this before I found this patch I was considering making a twig extension to provide the behavior but luckily we found this patch that already has been perfected and a lot of work has gone in (thanks mostly to Lendude!)

I got #140 running on 8.7.4 without having any problems

I updated a script that git clones over 24012 contrib projects for Drupal (modules mostly), just need to adjust it to checkout the 8.x branches automatically, then grep all those. There's probably well over 5000 of those projects that have 8.x branches but I haven't checked yet. Still need to update the script to look through 8.x branches.
#1057386-82: Provide a way to download the entire git codebase for all projects

with that said, this is probably overkill for checking this patches impact on contrib.

Also confirming #140 works beautifully on 8.7.4.

This is to confirm that the #140 works for us also(Drupal 8.7.2). We experienced an issue with the RSS feed link in Views. For us, we created separate RSS views for English and French to push content to MailChimp. The problem we faced was with the French RSS feed whose link instead of pointing to French node was pointing to English. The patch mentioned in #140 worked for us.

I confirm that the #140 works for us (D8.7.5).

We're using #140 in two projects on D8.7.5 and it works like a charm.

From #161

I'm not keen on backporting the changes to a base class constructor to a patch release, maybe for a fatal error or data loss, but this is neither.

On that basis, marking this as fixed.

Any chance this will be released in Drupal 8.8?

@markdatter , it's already in 8.8.x , 8.8.0 will be released in December I believe, should include this.

I would like to see this fixed in 8.7.x as well, however it's probably not going to happen, 8.8.0 is just around the corner two months away.

Hi

I have patched 8.7.7 with #140 but User Entity still doesn't link to correct current language.

This problem happens on user display render and also on views fields from user entity.

Anonymous or Authenticated logins when they click on a User link that is configured with "Link to content" (user picture) or "Linked to the User" (text field) always go to default lang (no lang path in my case) then the current site selected language.

EDIT: SOLVED!

The fields which we want to "Link to content" or "Linked to the User" must be multilang.
So I was linking for "Full Name" field, and that wasn't multilang (doesn't make sense). But for the links to work language sensitive, the field must also be multilang.
That's it...

@jrochate, correct me if I am mistaken but if my recollection is accurate this solution resolves field language for linked reference to other entities of type node in a view. For type user likely keep searching the issue queue , someone has surely written a patch. Otherwise please review if the patch was applied correctly and clear caches.

Do I get this right? This issue is resolved in development version and will be resolved in the next 8.x release?

For 8.7.x use the patch, however the comming release 8.8.0 has this fixed

Can anyone confirm if 8.8 fixed the issue for them?
It did not in my case.

I haven't yet upgraded to 8.8.0, maybe in a few weeks.

However, FOR SURE this is fixed in 8.8.0

Try to apply the patch, it will say it's already applied!

When upgrading from 8.7.6 to 8.8 I got this message:

https://www.drupal.org/files/issues/2745755-19.patch (AliasStorage::preloadPathAlias() incorrectly prioritizes UND aliases; https://www.drupal.org/project/drupal/issues/2745755)
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2745755-19.patch

Reviewing the code it already contains the patch so we don't need this patch in 8.8!!.

@efrain, please move this discussion over to #2745755: AliasStorage::preloadPathAlias() incorrectly prioritizes und aliases
seems obvious to me that the patch you refer to needs a reroll (if it's still needed, you should verify that, might be a stale issue).

Can someone confirm that this issue is fixed in 8.8 for all views, including REST?

I have a REST export on nodes with a link field and all entities referenced by this field show URLs in the original lang, translations are completely ignored.

Maybe open a new issue for the REST use case with steps to reproduce and link it to here.

Meanwhile maybe try workaround with:
https://api.drupal.org/api/drupal/core%21modules%21views%21views.theme.i...

@joseph I'm not sure which workaround you're referring to. I don't think the output of REST views can be modified via template preprocess or am I missing something? 🤔

Again, off topic now because your issue is not the same. Alternatively as a workaround, you can also load a REST view in a controller method and for a new route and output a modified json array from that.

ex:

    $view = Views::getView('newsitems');

    $view->setDisplay('rest_export_1');
    $view->preExecute();
    $view->execute();

    // $myresults = $view->preview();  = array
    // $myresults = $view->render(); // = array
    //$myresults = $view->result; // = array
    $custom_results = [];
    foreach ($view->result as $id => $result) {
      $node = $result->_entity;
      $custom_results[$id]['summary'] = $summary;
      $custom_results[$id]['nid'] = $node->id();
      $custom_results[$id]['title'] = $node->getTitle(); // $node->getTranslation('de')->getTitle() will get you german.
      $custom_results[$id]['title_fr'] = $node->getTranslation('fr')->getTitle(); // Français.
    }
    ksort($custom_results, SORT_NUMERIC);
    return new JsonResponse(['status' => TRUE, 'message' => ['These are json results'], 'data' => [$custom_results]]);

This issue is already closed, please do not put any more responses in this thread other than the link to your somewhat related issue.

I will not respond to any more of your questions in this thread

please open a new issue and put the link here.

A quick and easy workarround that I use for views pages (need pathauto).

Create your page view as usual and set URL in default language e.g. "/english-title".

Then go to admin - search and metadata - url aliases (/admin/config/search/path)

Add alias, on "system path" add link you have created on view "/english-title" and then on "url alias" add translanted link "/titulo-ingles"

Click save and thats it, now you have your views page translated.

Closed #2667086: LinkBase doesn't respect translations as a duplicate, adding credit.