Field type list_string tokens are not translated, always original language

Just ran into the same issue. We needed the value from a list_string field to build the URL alias. The list_string values are all translated, but the tokens result is always returned in the original language.

Setting the priority to Major as it breaks expected functionality for translations and there's no workaround.

Adding more or less related issues on translation.

Same issue here using a list_string type field with translated labels supposed to be used by pathauto to generate the path of the node.
That part of the path is always in the default language.

I traced that down to the $entity->$field_name->view($display_options); call in _field_tokens() where I found something really strange happening (which seem to be a Core issue).

$entity->$field_name->language()->getId() returns the appropriate language.
$entity->$field_name->getEntity()->language()->getId() (first thing done by the \Drupal\Core\Entity\EntityViewBuilder::viewField() method) returns the default language!

I didn't find anything related to that issue in the issue queue and I'm not sure I know how to file that. Any help would be appreciated.

@duaelfr reading this I think it might be by design as $entity->$field_name->getEntity() might return the "original" entity (not the translation of it), so back there it might need ->hasTranslation() (https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!ContentEnt...) again like you never had the language.

So it might be expected and by design, but unintuitive. So essentially the language argument then seems to be missing somewhere over there?

@anybody You must be right about getEntity() as the \Drupal\Core\Entity\EntityViewBuilder::viewField() method calls \Drupal\Core\Entity\EntityRepositoryInterface::getTranslationFromContext() right after. The thing is that it does the call only for untranslatable fields and without any langcode so it fallbacks on the content language which is not the one we expect in most technical cases.
In my case, the field is not translatable so it wouldn't work anyway… I'll give a try to the #7 patch even if it looks a but hackish.

The closest issue I found in Core is #2606322: FieldItemList::view() does not display fields in the correct language → which has been marked as duplicate of #2955392: EntityViewBuilder::viewField() does not respect entity current language when used with an entity reference field → .
Do you think we should reopen it to discuss our use case there?

Mhm unsure, both look quite old, so might be unrelated. I'm still not sure if the issue is here in the token implementation or in core. Sadly I don't have time for deeper investigations currently, sorry.

I think it would be best, if you could find similar places or calls on Core or if we had a clean MR for token to resolve this.
If that's not possible due to Core API design, I'd vote for a new core issue. Or you could try to discuss this in slack perhaps?