- π¬π§United Kingdom Paul Rowell
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:
- Status changed to Needs review
almost 2 years ago 3:51pm 1 February 2023 - π·π΄Romania bogdan.dinu
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").
The last submitted patch, 17: linkit-3041045-localise-link-config-17.patch, failed testing. View results β
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.- Status changed to Needs work
almost 2 years ago 12:33pm 3 February 2023 - π·π΄Romania bogdan.dinu
re-roll of patch #17 with coding standards fixes
- π·π΄Romania bogdan.dinu
previous patch was broken. please use this one.
- Status changed to Needs review
almost 2 years ago 9:58am 20 February 2023 - π§πͺBelgium ludo.r Brussels
#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. - πΊπΈUnited States mark_fullmer Tucson
This might be a problem if you want to show items in other languages than the current page language.
Good point. The proposal in β¨ Multilingual support: Allow linking to specific translations Needs review 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.
- π·π΄Romania bogdan.dinu
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. - Status changed to Postponed: needs info
over 1 year ago 2:55pm 24 March 2023 - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
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:
- β
\Drupal\linkit\Plugin\Filter\LinkitFilter::process($text, $langcode)
uses$langcode
to load the appropriate translation of the entity:$entity = $this->entityRepository->getTranslationFromContext($entity, $langcode);
- β
That
$langcode
came from\Drupal\filter\Element\ProcessedText::preRenderText()
invoking filter plugins, and it got that itself from$langcode = $element['#langcode'];
. - β
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!
- β
- πΊπΈUnited States mark_fullmer Tucson
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 β¨ Multilingual support: Allow linking to specific translations Needs review ?
Put simply: this current issue proposes to provide the *current* language of the entity being edited in the autocomplete suggestions, while β¨ Multilingual support: Allow linking to specific translations Needs review 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.
- π¨πΏCzech Republic Bohus Ulrych Pilsen (Czechia)
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. - Status changed to Needs work
10 months ago 4:15pm 8 February 2024 - π©πͺGermany mkalkbrenner π©πͺ
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.
- Status changed to Needs review
10 months ago 11:15am 9 February 2024 - last update
10 months ago 82 pass, 2 fail - π©πͺGermany mkalkbrenner π©πͺ
I completed the patch so that
Canonical
substitution uses the current languge. I also fixed theSubstitutionInterface
.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.
- last update
10 months ago 82 pass, 2 fail - π©πͺGermany mkalkbrenner π©πͺ
I accidentally removed a commit. Here's the adjusted patch.
The last submitted patch, 30: 3041045_30.patch, failed testing. View results β
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.The last submitted patch, 31: 3041045_31.patch, failed testing. View results β
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.- π¬π§United Kingdom james.williams
james.williams β made their first commit to this issueβs fork.
- π¬π§United Kingdom james.williams
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?
- Merge request !63Issue #3041045 by bogdan.dinu, mkalkbrenner, Ben_A, Paul Rowell, k-l,... β (Open) created by james.williams
- π¬π§United Kingdom james.williams
james.williams β changed the visibility of the branch 3041045-7x-allow-using-current-language to hidden.
- π¬π§United Kingdom james.williams
james.williams β changed the visibility of the branch 3041045-7x-allow-using-current-language to active.
- π¬π§United Kingdom james.williams
james.williams β changed the visibility of the branch 3041045-allow-linkit-url to hidden.
- π¬π§United Kingdom james.williams
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.
- Status changed to Needs review
3 months ago 3:56pm 22 August 2024 - π¬π§United Kingdom james.williams
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?
- πΊπΈUnited States mark_fullmer Tucson
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 β¨ Multilingual support: Allow linking to specific translations Needs review 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.
- π¨πSwitzerland berdir Switzerland
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.
- Status changed to Needs work
3 months ago 9:49am 23 August 2024 - π¬π§United Kingdom james.williams
Thanks for the encouragement @mark_fullmer and the wise warning @berdir! I suppose the caller (LinkitFilter) could set 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 :)
- π¬π§United Kingdom james.williams
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.
- Status changed to Needs review
3 months ago 12:16pm 23 August 2024 - π¬π§United Kingdom james.williams
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.