Contrib.social

Rendered HTML Output doesnt respect activeLanguage completely

Open on Drupal.org →
Created on 26 February 2019, over 5 years ago
Updated 2 February 2024, 5 months ago

At first I had some troubles, getting the metatags in the correct language of the current node while indexing.
Trying to find some hints on how search_api does things with its rendered html output, I found the same problem there too.

What I want to do
Index the rendered HTML output of multilingual entities

What I expect
Get the HTML of the page, with everything being rendered in the entities activeLanguage language

What happens instead
The (most) rendered fields of the entity are in the correct language, the entities activeLanguage at index time.
Other parts of the HTML Output however are in the current active backend language.

I have tested this only with running the index job on the drupal backend or the drush console,
but I do believe it also applies to cronjobs but not while updating & indexing immediatly (if the setting is used), it only updates ONE node translation, and not several at ones.

Some more info on the setup:
on the "Detect Languages" configuration site, only Interface Language Negotiation is active, with URL and Browser being set.
there are 4 languages active for each node.
i have checked if the indexed nodes have the correct translation for their set language.

Investigations
Any time some rendering happens, this might have an effect.
So the actual problem was this kind of code: (this one is taken from MetatagManager::generateRawElements()
\Drupal::languageManager()->getCurrentLanguage(LanguageInterface::TYPE_CONTENT)->getId();

Also entity reference field which get rendered on dont know their language yet, they might also ask the languageManager

In the end, I followed the second answer, switching out the LanguageNegotiater temporarly
https://drupal.stackexchange.com/questions/156094/switch-a-language-prog...
Using a custom Negotiator while getting the metatags
and for the rendering the entity, I extended the RenderedItem and overwrote the function addFieldValues and added the same lines.

Some more thoughts
This 'bug' occurs only when some code would want to render the page in a different language than negotiated from the languageManager.. Since normally, it is a good idea to ask the languageManager "what is the current language I should render things in?",.. But since, in the case of search_api, the current entity rendered might have a different activeLanguage than the languageManager might return, things dont fit together anymore.

Usually other factors determine which language the entity will be rendered in, through the conditions you can activate (Browser, URL, User, System, ...) Maybe there should be a Condition for the languageManager which respects the current rendered entities activeLanguage? Or you can set it programmatically only and it gets ignored usually?

This might not only affect search_api but any other case if something is rendered in a different language than negotiated by the languagemanager during the same "page call".

🐛 Bug report
Status

Needs work

Version

1.11

Component

Plugins

Created by

🇦🇹Austria vierlex

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024