Problem/Motivation
We've long wanted this functionality.
I brought it up July 21 2020
wondering if it would be possible to allow the tokens to process a language suffix in the token to get the specific language value otherwise grab the current interface language
@berdir had this to say July 22 2020:
The language is passed in as an option, token syntax simply isn't flexible enough to allow arguments like that. Each token has one type and has to pass things to its children.
It would also explode the number of tokens which is already a massive concern.
In response to @berdir, obviously for us wanting this functionality, it should only be enabled when there are multiple languages available so I don't see the argument for concern about the number of tokens. It could be also an optional functionality which could be disabled by default but enableable.
The missing tokens are:
(examples):
[term:field_company_code:fr]and[term:field_company_code:nl][node:field_name:fr]and[node:field_name:nl]
OR, if it's easier to do it this way:
(examples):
[node:fr:field_company_code]and[node:nl:field_company_code][node:fr:field_name]and[node:nl:field_name]
OR maybe we hack something in like this:
(examples):
[node_fr:field_company_name]and[node_nl:field_company_name]- we could check the token for the string , if it's
node_xx, string parse it and set the langcode toxx.
OR hack something like this
- OR
[node:field_company_name_fr]and[node_nl:field_company_name_fr] - we could check the token for the string , if it's
field_company_name_xx, string parse it and set the langcode toxx.
We need to have standard tokens for things like nodes which are for a specific language. For things like multi-language emails it is not sufficient to simply use the current context language to determine the language of the token value.
So for a token like this: [node:field_shared_node:entity:title], we need something like [node:field_shared_node:entity:title:fr]
not sure the best format for this, just adding langcode to the end seems like it would be difficult to parse as not being for something else. Looking at date tokens as an example they do not seem to worry about this as these are all valid:
date:custom:?
date:format_1
date:format_2
Maybe something like: [node:field_shared_node:entity:title:language:fr] would be preferred?
I have seen a few other language specific token issues and this exact issue reported in one of them but the reply was that it was out of scope of that particular issue - so guessing this hasn't yet been requested in its own issue. Apologies if it has been.
Also, not sure if this would be part of this module or perhaps its own contrib module?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork token-3276537
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
liquidcms commentedComment #3
joseph.olstadYou can implement your own tokens in your own my_module module. Sorta like this:
Comment #4
joseph.olstadthis link might help
Comment #5
liquidcms commentedThanks Joesph, yes, i know how to make custom tokens (this would be my last resort).. was just looking for a more dynamic method than creating them every time a new field is added and more specifically, suggesting this should be part of the token module.
Looking at dynamic code now.
Not sure what the link you posted has to do with this; that is just about tokens for the language - not what this is about.
Comment #6
joseph.olstadHi @liquidcms, yes I'm also interested in what you're wanting to do, have done something similar but it's blurred right now, if I find something more relevant I'll share it. Please keep us updated on your progress.
Thanks!
Comment #7
joseph.olstadComment #8
joseph.olstadComment #9
joseph.olstadComment #10
joseph.olstadComment #11
joseph.olstadComment #12
joseph.olstadComment #13
joseph.olstadComment #14
joseph.olstadComment #17
joseph.olstadTest results look great.
testTranslationTokens is passing in all phpunit runs.
Unrelated fails in next minor.
Comment #18
das-peter commentedCame across the lack fo translation value access too - decided to give this a first go.
Went with the entity level switch:
[entity:t:*]->[entity:t:en] [entity:t:de] [entity:t:zh-hans]etc.Reason is that the translation handling happens on entity level (
->hasTranslation(),->getTranslation()) so resolving as early as possible should hopefully help resolving in the requested language down the chain.I didn't really like having floating language token on the entity - hence the
tgroup - essentially an homage tot():P.Encountered some issues with the first draft that was re-using existing token types - switched to a dedicated translations token type per translatable entity type approach to work some of the encountered limitations.
Still doesn't feel ideal but I've no idea if that could be streamlined without causing more trouble than it's worth it.
Tests have been added and pass.
The pipeline failures about code style seem to refer to untouched code.
Reviews would be great.
@joseph.olstad Thanks for the quick response! You were faster than I could wrap up my comment :)
Comment #19
joseph.olstadthe :t: prefix is likely a good call, not too hard to figure out. Hopefully there's a helper for this in the token list.