Rendering is not changing the current content and string translation language

Created on 9 August 2023, over 1 year ago
Updated 2 February 2024, about 1 year ago

Problem/Motivation

During the rendering of content entities search_api is not changing the current content language to the translation language of the item being processed. This is an issue only when the content is indexed through the UI job or through drush, but not when indexed on saving. The issue itself is caused when for example in a preprocess hook string translation is being used that relies on the current interface language. This would lead to showing messages that are indexed as part of the content in the interface language that the user was on while executing the indexing job instead of going for the current language of the item being indexed.

Steps to reproduce

See Problem/Motivation

Proposed resolution

When indexing change the current content language and the language for the string translation service to the language of the item being processed.

Remaining tasks

๐Ÿ› Bug report
Status

Closed: duplicate

Version

1.0

Component

Plugins

Created by

๐Ÿ‡ฉ๐Ÿ‡ชGermany hchonov ๐Ÿ‡ช๐Ÿ‡บ๐Ÿ‡ฉ๐Ÿ‡ช๐Ÿ‡ง๐Ÿ‡ฌ

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

Comments & Activities

  • Issue created by @hchonov
  • Status changed to Needs review over 1 year ago
  • Open in Jenkins โ†’ Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 8.1 & sqlite-3.27
    last update over 1 year ago
    Patch Failed to Apply
  • Open in Jenkins โ†’ Open on Drupal.org โ†’
    Core: 9.5.x + Environment: PHP 8.1 & sqlite-3.27
    last update over 1 year ago
    538 pass, 2 fail
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany hchonov ๐Ÿ‡ช๐Ÿ‡บ๐Ÿ‡ฉ๐Ÿ‡ช๐Ÿ‡ง๐Ÿ‡ฌ
  • Status changed to Needs work over 1 year ago
  • ๐Ÿ‡ฆ๐Ÿ‡นAustria drunken monkey Vienna, Austria

    Thanks for reporting this problem and already providing a patch!

    First off, itโ€™s important to note that, in general, no UI text should be present in the indexed HTML contents of an item, since that would lead to useless results. E.g., if your rendered item all contained a โ€œTags:โ€ field label, then you couldnโ€™t search for the word โ€œtagโ€ anymore without receiving every single piece of content as a result.
    However, some setups of course use rendered fields in the index just as a storage, sort of a cache, to be able to display results faster, without loading the entity. In this case, of course, you want the HTML exactly as it appears on the page, including all UI text. And then I guess you will run into this problem.

    Regarding your patch: Iโ€™m always very hesitant to change the global application state during indexing, as it seems almost certain that this will lead to problems in some scenarios. However, as we can see by the code that is already in RenderedItem::addFieldValues(), this cannot really be avoided without sacrificing reliability of the generated field values. So, I guess we might need to change the translation language, too, as you indicate โ€“ and just hope it doesnโ€™t lead to more problems than it solves.

    However, this patch is definitely missing two things:

    1. Code that switches the language back after indexing (unless Iโ€™m mistaken?)
    2. A regression test demonstrating the problem and that it is actually fixed by this change

    Would be great if you could add these two things. In any case, thanks again!

  • ๐Ÿ‡ง๐Ÿ‡ชBelgium swentel

    Hmm, is this related/the same as ๐Ÿ› Rendered HTML Output doesnt respect activeLanguage completely Needs work

  • Status changed to Closed: duplicate about 1 year ago
  • ๐Ÿ‡ฆ๐Ÿ‡นAustria drunken monkey Vienna, Austria

    @swentel: Youโ€™re right, thanks for noticing!

    @hchonov: Please see whether the patch in #3035977-43: Rendered HTML Output doesnt respect activeLanguage completely โ†’ resolves the problem for you, too. Otherwise, please re-post your patch there.

Production build 0.71.5 2024