The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Hi and thank you for this great module. Token filter + Custom tokens are very very useful and we're using it since years :)
In Drupal 8 custom tokens can easily be translated into different languages through the cure entity translation capabilities. That works great. Sadly the token is always being output in the default / first language, even if a different translation exists for the current interface language, when using token filter for text formats.
The reason can be found in TokenFilter.php Class, line 114. The $langcode is not passed to ->process here, but should be: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Utility%2...
/**
* {@inheritdoc}
*/
public function process($text, $langcode) {
$data = [];
$entity = drupal_static('token_filter_entity', NULL);
if (!is_null($entity) && $entity instanceof ContentEntityInterface) {
$token_type = $this->tokenEntityMapper->getTokenTypeForEntityType($entity->getEntityTypeId());
$data[$token_type] = $entity;
}
$clear = $this->settings['replace_empty'];
$replacements = $this->token->replace($text, $data, ['clear' => $clear]);
return new FilterProcessResult($replacements);
}
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | token_filter_8.x_fix_token_language_determination-3063657-11.patch | 625 bytes | spadxiii |
| #6 | token_filter_8.x_fix_token_language_determination-3063657-5.patch | 592 bytes | anybody |
Comments
Comment #2
anybody## Moved to token_filter module where this bug belongs! ##
Comment #3
anybodyComment #4
anybodyComment #5
anybodyAttached you can find the patch which fixes this problem. We've tested it manually so far and it works like a charm. Feel free to write some tests on it.
Please review.
Comment #6
anybodySorry... patch attached ...
Comment #7
darvanenGood find, thanks @Anybody.
Once this has some tests I'll happily review/commit it, along with the related D7 one.
Comment #8
WidgetsBurritos commentedUnfortunately, I don't think we can rely on the $langcode value coming into the process method. It assumes the node you're looking at actually has a translation for the current language you're looking at. That may not always be the case.
Consider this scenario:
1. You use a module like language hierarchy to provide language fallback functionality for various regions. For example:
English:
-> /en-us
-> /en-gb
2. You create a node in the base English language that contains a token.
3. You visit that node in /en-gb. Because the node was created using the primary english translation, if you visit /en-gb, the filter module will pass in `en` as the langcode, despite the fact you're visiting the page in en-gb.
But, if you've created a translation for the token itself in /en-gb, and place it on a node with only the base translation.
Grant it, language hierarchy itself is an alpha module, but it's really just a UI wrapper around hook_language_fallback_candidates_alter() which is provided by core.
An example where someone would want to do something like this is when you want the content on the page to be the exact same, but you want to show a different phone number for the US/GB offices.
Now start adding in other languages/regions, and it gets more and more complicated to manage, especially if you rely on translation vendors to translate the base language, and use tokens to replace regional content.
Comment #9
WidgetsBurritos commentedThe more I think about my comments in #8, I think this is a core issue. I opened #3067999: ProcessedText filter doesn't pass in correct language when using language fallback to address.
Comment #10
WidgetsBurritos commentedComment #11
spadxiii commentedQuick reroll of the patch in #6 so it applies again in the current version.
Comment #12
anybodyHi @WidgetsBurritos
while I understand your scenario and agree with you, I'm still thinking if it wouldn't be better in a first step to commit the fix in this module with a TODO and reference to this & the core issue than keeping the module in a worse state and wait for the core issue ever to be maintained.
What do you think?
Comment #13
anybodyWe're using the patch #6 / #11 since > 1,5 years now successfully and they solve a major problem for i18n pages. I'd very much vote to commit it and have a solution for multilang at all. If it's required we might have a follow-up. But just my two cents... :)
Comment #14
darvanenThanks for your input @Anybody but the patch needs more than one voice supporting it, it's too easy to break implementations other than the one that spawned the patch.
I don't understand the language system well enough to review it. Like I said before, once it has been thoroughly reviewed (to my satisfaction) I'll happily commit it.
Comment #16
darvanenRevisiting this with a year's more experience, no issues here. Committed.
As for the scenario described in #8, I agree with #12.
Comment #17
anybodyThank you so much @darvanen, that's great news for us, now we can remove the patch from many many projects! :)
Comment #18
anybodyPS: New release planned?
Comment #19
darvanenYou're welcome, and yes, I'm just hoping to get a review of #3051268: Migration path: filter_tokens (7.x-1.x) → token_filter (8.x-1.x) so I can pop that in too.
Comment #20
anybodyYay! Released with 8.x-1.4! :) Thank you so much, happy to remove the patch now!