Create per-language tokens

Yes we need this as well. See #3029752: Language token links, provide them for enabled languages

I developed this patch which solves our problem when creating an access token while editing the French version of a node.

@dsutter , nice work on that patch!

Triggering simple tests /automated tests.

I'm going to say that this patch is good! Great work @dsutter !

I'm working on an edge case fix for this fix.

draft nodes token access that aren't published works with this patch in all enabled languages (great job!)

However with or without the patch, forward draft revisions (latest draft) of a published node work only in the source language.

I've debugged to a certain point, basically what I've found is the access_check for this situation the source language entity is loaded, if I do a check for type node and language not equal to the entity language, getTranslation brings back the 'fake' revision and the token access checks fail in this situation.

explanation here:

https://www.drupal.org/project/drupal/issues/3033324

My next approach to this will be if exists to get the non-fake latest revision entity of the current language of the token request. I am hoping this will fix this use case. I will try this approach soon.

I finally found the fix to #6. The issue is not with access_unpublished , NOR is it with content moderation, the issue is with core language negotiation and there's a core fix.

So, to get full functionality apply the above patch #3 AND also this core patch:
#2951294-21: Sort out and fix language fallback inconsistencies

Access unpublished patches we're using:
#2958800-3: Create per-language tokens
#3054536-9: access_unpublished twig extension for displaying hashtag

Related (highly recommended) core patch:
#2951294-21: Sort out and fix language fallback inconsistencies

Why was this not included in beta2 ?

The current solution only loads the entity in the current language, which is not what is requested by this issue.

Instead we need a new field on the Access Token entity - "langcode". Then when creating the token we need to supply the langcode of the current entity and when loading the entity in ::getHost() we need to retrieve the corresponding entity translation.

@hchonov, I've used this patch on several installations with more than one language and it provides the tokens per language as desired. The token gets generated in the correct language as per the usage.

If you have a better idea, then please present your patch and I will test it. With that said, the above mentioned patches all work together.
see comment #8 , you should apply both or all three of these mentioned patches and follow the instructions mentioned the third patch issue

Try changing the langcode in the URL that you are copying and you will see that you get access to other translations with the same token. The idea of this issue is to have an access token per translation and not an access token for the whole entity.

In our use case this is exactly what our client wants, they are bilingual in our case, they want an access token for the entity not just one translation of an entity. Perhaps a config option to add for your use case.

There are several big important projects that I know of that are using this patch

patch still applies to 1.3 cleanly