getTranslatedFieldFromEntity should use the content language

I tested this and can't reproduce it with the latest version 8.x-2.0-alpha5 and:
1. Created a node in en
2. Translated in de
3. Put the field body as a block
4. Getting different content (translation) when I visit en/de site.
Can you please give more info on how to reproduce it or it's maybe fixed in the recent releases...

Thanks, closing this until we get more info.

I'd like to open this up again as I can reproduce the issue.

We're using Drupal 9.5.5 with the Sector Distribution.

When I add a field as a block, like the subtitle or banner image field (all with translations enabled) and using Content language (instead of interface language), when I add a translation, I expect to see the translated content on the page, but I see the original languages content.

The patch at https://www.drupal.org/project/fieldblock/issues/3173729#comment-13840638 works for me.

Looks like we need to update the patch for 2.3

@stewest updated patch for 2.3

I've tested this updated patch and it works

rather than the old patch "Use content language rather than interface": "https://www.drupal.org/files/issues/2020-09-28/fieldblock-content-lang_3..."

Just moving this to the dev branch version.

Thanks everyone for the testing, updated patches, and digging into this over the years. I think we have a solid picture now of why this fix is the right one.

Core's parameter converters already hand the block the content-language translation — both EntityConverter and EntityRevisionParamConverter resolve the entity translation through the content language. So getTranslatedFieldFromEntity() was undoing the translation core had already selected, switching it back to the interface language. Using TYPE_CONTENT isn't just the safer option, it matches how the entity arrives in the block in the first place.

That makes me think we can close out the second proposed option, a per-block content/interface language toggle. If someone has a use case for it later, it feels better suited to a separate feature request.

I also looked at the EntityAdapter::createFromEntity() + setContext() handling. It works, if indirectly: setContext() changes the parent rather than the field values, and EntityViewBuilder::viewField() builds from $items->getEntity(), so the translated parent entity is what determines the rendered value.

I've added regression coverage that negotiates the interface and content languages separately: interface fixed to English, content taken from the URL prefix. That's the configuration where the two can actually disagree; with the default setup the content language follows the interface language, which helps explain why this was difficult to reproduce earlier in the issue.

The tests cover three cases:

• a translated node renders the appropriate value for the content language;
• an untranslated node falls back to its source language; and
• the block declares the languages:language_content cache context.

Worth noting that the two lines of the patch belong together. /node/1 and /de/node/1 resolve to the same route with the same parameters, so the route context alone doesn't vary per language — the content language context is what lets the block cache correctly. The translation test requests English before German for that reason, and there's a note on the method so the ordering doesn't get rearranged later.

AI disclosure: I used AI to help generate the tests. I reviewed and directed the resulting code, including its style and approach. Used DDEV locally to manually test to make sure I didn't introduce a regression.

My manual test scenario: interface language fixed to English via language-selected, content language from the URL prefix... the only configuration where the two can disagree. Article has a translatable field_subtitle, hidden from the node view display so the field block is the only thing rendering it, placed in Olivero's Content Above region.

German field block before fixes, after node/1 cached as English:

German field block after fixes, after node/1 cached as English: