Allow "Linkit URL converter" filter to generate links based on the language of the current page, rather than the language of the referenced entity

I've had the same requirement in a project but I think this should be configurable, whether the link should switch to the language of the referenced entity or if it should stay in the current.

Also see #2886455: Multilingual support: Allow linking to specific translations

Hi all,
I'm also fighting with this.

I have Node1 in English only with link to the Node2, which exists in English and French. If I'm displaying Node1 on the French version of the site, link is always created for the English version of Node2.
I think this is because langcode of such "French" node is still en. This is then applied in the LinkitFilter.php
public function process($text, $langcode) {

If I rewrite $langcode with the current interface language
$langcode = $language = \Drupal::languageManager()->getCurrentLanguage()->getId();
then my link is created correctly to the French version of Node2.

Do I miss something? Or is there any better way how to do it? I was checking #2886455 but I think it tries to solved another problems.

Thanks

The reason is because although the filter sets the entity to be the translated version;

// LinkitFilter.
$entity = $this->entityRepository->getTranslationFromContext($entity, $langcode);

...when it comes to making the link, it doesn't do anything with that information and just generates "a link".

return $entity->toUrl('canonical')->toString(TRUE);

https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!EntityBase...

It needs the langcode passed into the method to utilise it. I've attached a patch which I made completely separately as I've only just seen this issue ... it's remarkably similar though!

+++ b/src/Plugin/Filter/LinkitFilter.php
@@ -102,11 +114,12 @@ class LinkitFilter extends FilterBase implements ContainerFactoryPluginInterface
 
             $entity = $this->entityRepository->getTranslationFromContext($entity, $langcode);
+            $attributes = ['language' => $this->languageManager->getLanguage($langcode)];
 
             /** @var \Drupal\Core\GeneratedUrl $url */
             $url = $this->substitutionManager
               ->createInstance($substitution_type)
-              ->getUrl($entity);
+              ->getUrl($entity, $attributes);
 

$entity does use the active language with toUrl(), see https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21..., where it passes along the language().

So this is only a problem if there is no translation of $entity for $langcode.

Passing attributes along like this is an API change, but you wouldn't need to do that, you could just set the option on the returned Url object.

Not sure if we should do that without making it configurable as it is a bit of a grey area between bugfix and behavior change IMHO.

Agreed this probably something that needs to be configurable given the maturity of the module. Hard to sell a change like this without a way to revert it to how it works now. That said, I agree the current behavior feels wrong.

Currently linkit is outputting links using the translated language of the entity being viewed.

Scenario:
Languages "English" and "Spanish" on site ("English" is default)
node/1 has only an "English" translation.
node/2 has both "English" and "Spanish" translations.

On node/1, there is a link to /node/2 via LinkIt.

When viewing /es/node/1 (Spanish URL), the link to /node/2 will be output as:

Current behavior: /node/1 (the English version), because LinkIt uses the translation of entity being viewed. And since the translation being viewed is English, it will always output target links in English. Basically the Spanish URL context is ignored.

New behavior: /es/node/2 (the Spanish version), because LinkIt will use language context.

FYI Patch #6 is not working for me. Still only solution which I'm using is overwrite $language in "public function process($text, $langcode)" as mentioned in #5

Hello, still active topic for me.
There are many combinations of language values : nodes can be translated or not, attached Paragraphs may be translated or not, linked page may be translated or not ...
It seems that now works for me in all cases patch #6, but with additional modification - overwriting $langcode in the process():

$langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();

Tested with Drupal 9.2.4

@bohus you're exactly right. I wish I'd read your comment before debugging and creating my own patch from #6. Here's my version, which is a copy of #6 with the adding of to the process() you've mentioned.

Latest patch has whitespace damage and cannot be applied. It also has an added comment that does not follow code standards. And it does not address the previous comments in #7.

I tried to improve the issue's title and description.

As far as I can understand, a remaining problem is that the linked entity may not have a translation in the current language, or that it may be unpublished. In both cases, I think leaving the link to /node/NID would make more sense.

(It could be argued that in these cases the link should be removed because if the visitor does not have access to it, there is no value in clicking on it. But I guess this could be a separate issue - and likely affects the published status of content in a single language, or when the node does not exist at all...)

I tried apply patch #12 and it says "

error: corrupt patch at line 63

"

Heya,

We needed this func/feature for a language fallback we have in place. I've taken the latest patch and added a configurable field in the filter:

Updating status

I've updated the last patch with a simple check on the default value for the form element because it was throwing a warning (Undefined array key "use_current_language").

re-roll of patch #17 with coding standards fixes

previous patch was broken. please use this one.

#20 works on my side and my use case, but I guess it's worth to mention that it does not exactly what the option claims:

Use the current entity language to generate a url (rather than the language of the referenced entity)

In fact it just gets the current language page rather than the referencing entity language.
This might be a problem if you want to show items in other languages than the current page language.

This might be a problem if you want to show items in other languages than the current page language.

Good point. The proposal in #2886455: Multilingual support: Allow linking to specific translations provides UI-based options for determining what behavior is desired. I think it would be good to either look at these approaches together and determine whether one can resolve the goal of both issues. If not, probably this issue needs some kind of configuration option to be able to show items in other languages.

I also ran into this issue recently and I think the best option would be to enable the language option on the link widget.
The link field supports for the language option and it will automatically generate the link in the selected language. The language selector can default to the current page language but the user will have the possibility to change it.
Unfortunately I didn't have time to implement it yet.

I'm very confused by this issue, and surprised it even exists! It may be because I'm not at all familiar with the "substitution plugin" part of the codebase.

Here's why I'm confused:

1. ✅ \Drupal\linkit\Plugin\Filter\LinkitFilter::process($text, $langcode) uses $langcode to load the appropriate translation of the entity: $entity = $this->entityRepository->getTranslationFromContext($entity, $langcode);
2. ✅ That $langcode came from \Drupal\filter\Element\ProcessedText::preRenderText() invoking filter plugins, and it got that itself from $langcode = $element['#langcode'];.
3. ✅ That in turn comes from \Drupal\text\Plugin\Field\FieldFormatter\TextDefaultFormatter getting it from the containing field item on the referencing entity itself: '#langcode' => $item->getLangcode(),

So … are we sure that this is a bug in/requires changes in the LinkIt filter plugin?

Because that plugin already has explicit translation-related test coverage specifically testing that the translation of the linked entity matches the language of the linking entity: \Drupal\Tests\linkit\Kernel\LinkitFilterEntityTest::testFilterEntityTranslations().

A failing test would make all the difference here!

I also ran into this issue recently and I think the best option would be to enable the language option on the link widget.
The link field supports for the language option and it will automatically generate the link in the selected language.

Would a more encompassing solution than this issue be taking the approach in #2886455: Multilingual support: Allow linking to specific translations?

Put simply: this current issue proposes to provide the *current* language of the entity being edited in the autocomplete suggestions, while #2886455: Multilingual support: Allow linking to specific translations proposes providing autocomplete results from *all* translations.

I couldn't get the patch from #20 to apply to Linkit version 6.0.2 so I re-rolled it.

Hi all,
FYI patch #27 can be applied on the version 6.1.2 too.

I'm on the English node, creating link to the English version of another node. Both pages are untranslated.
In the Japanese version of the site the link is correctly using path with language prefix (/jp/node/nid)
(don't forget to check "Use the current entity language ... " on the CKEditor / Linkit URL convertor settings)

Note:
In my case, I'm not happy to see in URL /jp/node/nid for untranslated pages. Therefore my own customization creates aliases for untranslated pages based on the original language. So it could be like /jp/my-title. But in such case, after applying patch, I will get URL /my-title (to the original language) instead of expected version with prefix /jp/my-title
I found that this is because in this version of the patch were removed modification in Substitution plugins (e.g. Plugin/Linkit/Substitution/Canonical.php) - compared to the #6. After applying this part of patch it works according to my expectations.

We faced a related issue. We have untranslatable commerce product entities with language undefined path aliases (which work for all languages).
All the links are generated using the site's default language 'en' instead of the the current content language.
For example, if you're on the German translation of a node you don't want to be sent to /en/product-path but to /de/product-path to stay on the German user-interface.

The patch in #27 solves that issue (partly).

+++ b/src/Plugin/Filter/LinkitFilter.php
@@ -107,12 +119,18 @@ public function process($text, $langcode) {
+              $langcode = $this->languageManager->getCurrentLanguage()->getId();

"current language" is not well defined. Is is the interface language or the content language.

If you use one of the contrib modules that allow editing multiple translations in parallel, it would be better to explictly get the language from the current form object.

I completed the patch so that Canonical substitution uses the current languge. I also fixed the SubstitutionInterface.

I didn't address the edge case of multiple translation in one form, because it might be out-of-scope for this module.

With this patch applied, LinkIt works for us.

I accidentally removed a commit. Here's the adjusted patch.

Re-rolled with config schema mapping added.

I've opened MR !62 starting from the latest patch in comment 35, and then added a commit to improve it based on the comments 22 and 29 - specifying to use the content type of language (as opposed to interface language and the confusing 'entity language' wording).

We should probably be using issue forks instead of patches going forwards anyway? I see the phpunit test job in the 6.1.x branch is failing to run successfully. Should we just move to targeting 7.x where the tests appear to work?

There we go; I've re-rolled the changes to go against 7.x in MR !63 and the test pass there. So I've hidden the MR for the 6.1.x branch (and all but the most recent patch file). But we haven't actually adjusted tests to start covering this issue yet.

As per comment 25 from Wim Leers, a failing test would make all the difference here .... well, we now have a test that does indeed fail in the tests-only feature, and passes with all the changes :) See https://git.drupalcode.org/issue/linkit-3041045/-/pipelines/261753 !

I've also updated the issue summary, hopefully that's now sufficiently clear and correct?

well, we now have a test that does indeed fail in the tests-only feature, and passes with all the changes :)

This is wonderful! Thanks so much. As a maintainer of the Linkit module, I am open to adding this to the module, given that it is an opt-in configurable feature. I just want to make sure everyone who is invested in #2886455: Multilingual support: Allow linking to specific translations as another multilingual feature request is still accommodated. I'll leave a comment on that issue for the followers to review this issue's updated description and where it's landed to allow a chance for more feedback before proceeding.

Adding a new parameter to SubstitutionInterface::getUrl() breaks BC.

7.x is technically only in alpha, but it's still challenging. There's an open issue in media_entity_download where people then get a fatal error when using this patch.

Doing this through the filter means this possibility is not available to link fields or it would need to be implemented separately there.

We needed this too in a project, and implemented it with a custom substitution plugin instead.

Thanks for the encouragement @mark_fullmer and the wise warning @berdir! I suppose the caller (LinkitFilter) setting the options on the returned URL instead of inside SubstitutionInterface::getUrl() might be fine, I'll test. I see that was actually suggested back in comment 7!

I'll also take a look at whether this only affects the filters, or if it's actually needed for link fields too. I suppose the canonical substitution plugin could even be swapped out for an equivalent plugin class that always uses the current language's translation. Anyway, these are thoughts I'll take away.

P.S. If no-one hears back from me on this for days, anyone else is welcome to pick this up again too, you can assume I got distracted by summer sun :)

OK, I see that yes, the field formatter is affected as well as the filter plugin.

@mark_fullmer @berdir which of the following approaches would you prefer:
1) Both the Filter & Formatter plugins just set the language option on the URL returned from the substitution plugin (duplicate code, but preserves BC and perhaps simplicity?)
2) Make the existing Canonical substitution plugin configurable, to optionally always use the current page's content language for the language option (rather than passing that in from the caller). Though that would then mean having to pass around plugin configuration.
3) Provide an additional substitution plugin which always uses the current page's content language for its returned URLs.

If you don't want that possible BC break in the current state of the MR, then I guess I'd lean to option 3.

Since my investigations helped me understand further, I'll answer Wim's comment 25 as to why this is an issue. Sorry if this is just unnecessary detail!
This is an issue because when a translation is missing, Drupal tends to fall back to showing another translation (e.g. the initial language version of the entity). So the $langcode is 'correct' in that it refers to the language of the content being displayed - but that's not necessarily the requested language for a page's content. (In the issue summary's example scenario, Danish is requested, but when that translation is missing, English is picked and then used throughout.) So in a sense this feature request is about respecting the requested language for onward links beyond the page's own main content - or at least having an option to choose between that or deferring entirely to Drupal's chosen fallback behavior. In summary:

A. Onward links within English content used as a fallback for missing Danish content, should be to Danish content, in order to preserve the requested language.
vs
B. Onward links within English content used as a fallback for missing Danish content, should be to English content, in order to preserve what the displayed content originally linked to.

I've added that comparison to the issue summary since that's hopefully a useful articulation of the issue.

Pushed approach 1 for now, as that is the path of least resistance and is along the lines of what Berdir had already suggested before.

I applied the commits to LinkIt v7.0.2 and it seems to work.

This option is very much necessary when you use the "Language Hierarchy" module with the Linkit filter. That module enables you to place languages in a hierarchy so that for example UK English (en-gb) inherits the translations from English (en). If you use the Linkit filter "Linkit URL converter" without this option/patch, the clearn URL's the filters provide will often be wrong. E.g. if the site interface is currently in UK English (en-gb) and you link to a node that is in the English translation (en), Linkit will link to "/en/..." instead of the desired "/en-gb/...".

There is one issue I noticed: the option "Use the current content language to generate a url (rather than the language of the referenced entity)" is always checked in the text format form. Even if I uncheck it and save it, after a refresh it will be checked again.

There is one issue I noticed: the option "Use the current content language to generate a url (rather than the language of the referenced entity)" is always checked in the text format form. Even if I uncheck it and save it, after a refresh it will be checked again.

@gillesv good spot! That was introduced back up in comment 17. I've added a fix in the MR.

Rerolled patch for the 7.0.4 version.

Merged 7.x into the merge request since there were conflicting changes.
Also adding a patch. See comment #55 for correct patch

Attached the wrong file in comment #54, attaching the correct one now

it seems it works ... MR rebased with the latest.

for me it looks ok ... but let's try other opinions/reviews.