bulk generating nodes with [node:content-type]/[node:title] uses current language for [node:content-type] for all languages

The token is defined in the token module.

I found a similar and related issue while using both Interface language and content language detection at the same time.

Here is a patch that worked for me at least, it fixes the language translation of the node content-type token when bulk generating node and also when saving node (when interface and content language detections are both enabled).

Yes, this look like the correct fix.

We should however also apply this to the content-type tokens a few lines below. Wondering if we can apply this in a more generic way.

Maybe the token replace service itself could enforce this when the passed language doesn't match the current one? That would solve a dozen similar tokens all at once.

That is in core although we override it. Not quite sure about pushing that into core, it's hard to get token related improvements committed there. But the same problem exists for example with the node:type-name token.

I agree this needs to be done once before all token replacements ; switching before each token gets generated will involve a lot more back and forth and there's a bunch of tokens where it'd be quite difficult to do (for example, token for List type fields where the human readable name can be translated).

Attaching a patch that wraps core replace method. Tested by mass generating aliases with patterns involving config entities, everything seems to work fine.

Patch 8 works well for me.

I come from:
https://www.drupal.org/project/pathauto/issues/2960064

This bug is important. It can potentially break all urls of all translated nodes.

Patch # 8 works well for me.

Thanks

#8 works well.

For me, this fixed the language of several tokens like term:vocabulary and also diverse tokens for Commerce (for example [product:producttype] ) Including DeFr and myself the modifications in patch from #8 has solved this problem for at least 5 people.
Seems to do the trick, so putting status accordingly.

Thank you very much for this, it literally cost me days to figure out what was going wrong here.

I still think this is a core problem that should be fixed there, instead of token.module, we don't provide the token API.

I'd appreciate if someone could create a core issue and corresponding patch, there might be open issues about that already there. Either way, it will require tests.

I agree with Berdir that drupal language in core is a mess.

With this patch I only get a partial fix on d9 as content url are still rendering in default language only

Pattern for URL Content still with default language TOKENS for D9.x

Is #2529182: Not all node, taxonomy entity tokens are multilingual aware the equivalent core issue for this?

Not sure if this is related with core, but if it is, it's not a problem with tokens.

I tried to debug this and this is what I found.
The token [node:content-type] is provided by the Token module and it's processed by the function token_tokens(), and its being replaced by the content type label generated at the following call:

$type_name = \Drupal::entityTypeManager()->getStorage('node_type')->load($node->getType())->label();

If the path is being generated by just saving the node, the EntityStorage language is set to the current node being saved, which is correct.
If the path is generated using a bulk action (as described in this issue) then the EntityStorage language is set to the site default language.

The patch provided handles this issue by overriding the config language, and that works, but I'm not sure if that should be done at this module.
I think that, ideally, EntityStorage should be aware of the entity language in some way.

Any thoughts?

config entity api doesn't support passing in the language explicitly, that needs to be done by setting the config language.

#2529182: Not all node, taxonomy entity tokens are multilingual aware is indeed related, you can see the logic for that in the token for the term:vocabulary token but I think node content type is not covered like that yet in there.

Added little code update to fix PHP 8.4 implicit nullable deprecation.