Problem/Motivation
Multilingual node support in search is broken in several ways.
1. The indexing uses the translated fields of the entity to render but not the translated title. So it is impossible to search in translated titles.
2. The search result rendering uses the translated node render but not the translated title. So it is impossible to see the translated titles, it is always the non-translated title displayed.
3. If a language condition is used, the search execution itself filters out nodes that do not have at least one translation in that language. Then it will find unrelated translations of the node (if the node has a translation in the requested language). Eg. if you search for Hungarian nodes only, it will search in all nodes which at least have a Hungarian translation, but it will find the node even if the search matches the German translation only (and not the Hungarian one).
Proposed resolution
1. When rendering the node for indexing, use the right translation. Ie. use getTranslation() for the right language so the title is rendered in the right language too. Add test coverage for this by translating node titles.
2. Fix the result rendering to use getTranslation(), so the results appear in the right language. Add test coverage so that the right language titles are returned.
3. Fix the field used to filter for language, so it does not only filter nodes that have the given translation (but then does not search in those given translations) to search in those given translations only (filter by indexed language instead of merely node language, this is a 1 char change :D). Add test coverage, so filtering for specific language only finds the node if available and matching in that language.
Remaining tasks
Review, commit.
User interface changes
None. The behaviour is fixed so now the search results come back in only the language requested (if requested specifics) and display in the right language. Also translated titles are searchable now.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#32 | searchfix-with-tests-32.diff | 6.63 KB | k4v |
#29 | searchfix-with-tests-29.diff | 6.63 KB | k4v |
#16 | searchfix-with-tests-4.diff | 6.63 KB | k4v |
#15 | searchfix-with-tests-3.diff | 6.62 KB | k4v |
#13 | searchfix-with-tests-2.diff | 6.6 KB | k4v |
Comments
Comment #1
k4v CreditAttribution: k4v commentedComment #2
k4v CreditAttribution: k4v commentedComment #3
Gábor HojtsyVery similar problem to #2006606: Views rendering ignores entity language, eg: Identical nodes rendered in views when nodes have translations and underlying label() API problem handled in #2142979: Entity label langcode argument is a lie, incompatible with current API. Needs tests.
Comment #5
Gábor Hojtsy1: searchfix-2142987-1.diff queued for re-testing.
Comment #8
Gábor Hojtsy1: searchfix-2142987-1.diff queued for re-testing.
Comment #10
k4v CreditAttribution: k4v commented1: searchfix-2142987-1.diff queued for re-testing.
Comment #11
k4v CreditAttribution: k4v commentedComment #12
Gábor HojtsyI don't think this comment is needed.
1. Its not added in the execute either.
2. get would be Get
3. We don't say "new entity API" because by this is released, used, etc. it will be the old one :D
I would move this comment up to where the body is set to be translatable. I think that already has a comment for that, If not, do something like "Set body to be translatable. The title is already translatable by definition." Or something along those lines :)
Comments should start with uppercase and let's use "English" and "Hungarian" properly cased :)
Remove this comment and open a new issue. We don't put comments about bugs in the code like this :D
Yet another issue to open :D So my understanding is this finds the second node based on "english" in the title and the third node based on "hungarian" in the title but then renders both of them in the same language?! Looks like this would be another bug. Maybe in fact the same bug as the previous comment :)
Don't remove the newline :)
Comment #13
k4v CreditAttribution: k4v commentedComment #14
Gábor HojtsyWrap at 80 chars.
english => English
hungarian => Hungarian
// followed by a space
dot at the end.
(In short always a full sentence).
Comment #15
k4v CreditAttribution: k4v commentedComment #16
k4v CreditAttribution: k4v commentedIn the last patch, i corrected only the comment length.
Comment #17
k4v CreditAttribution: k4v commentedComment #18
Gábor HojtsyUpdated issue summary extensively explaining all bugs. Retitled to cover the whole scope.
Comment #19
Gábor HojtsyFurther clarification of problem (3).
Comment #22
Gábor Hojtsy16: searchfix-with-tests-4.diff queued for re-testing.
Comment #23
Gábor HojtsyGood job k4v, this fixes all the right things the right ways and updates tests to be meaningfully looking for translations as well as prove the language filter works (unlike before :).
Comment #24
jhodgdonThis is a rather odd and non-intuitive DX. It looks like if I load a node and want to render it in a particular translation, I not only have to pass the language into the ->view() method, but before that I have to call getTranslation()? Why is that?
Anyway... That aside, this looks like a good fix to me and the tests are clear. I like that. :)
Comment #25
Gábor Hojtsy@jhodgdon: yeah the reason we need to do this is as follows:
1. We need getTranslation() because we need the title in the right language, and the current entity API works so you get whole variants of the entity and don't get properties in that language one by one.
2. However, if we don't pass on a langcode to the view method, it ends up in https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... which then takes the negotiated language for the page and will get that translation.
So if we want to have an explicit language, we need to pass it on although we already loaded that translation. That is the current API. I submitted #2144251: EntityViewBuilder may display different language if langcode is not specified after discussion with @fago and looking at https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
tl;dr: the patch uses the current API as good as possible :)
Comment #26
jhodgdonThanks for the explanation!
Comment #27
Gábor HojtsyElevating due to the amount of bugs this ended up covering.
Comment #28
catchJust minor code style nitpicks, otherwise looks good:
Extraneous blank line here.
Needs a space after //.
Hungarian should be capitalised, see also another hungarian and English below.
Comment #29
k4v CreditAttribution: k4v commentedComment #30
k4v CreditAttribution: k4v commentedfixed it.
Comment #32
k4v CreditAttribution: k4v commentedComment #33
k4v CreditAttribution: k4v commentedComment #34
catchComment #36
k4v CreditAttribution: k4v commented32: searchfix-with-tests-32.diff queued for re-testing.
Comment #37
Gábor HojtsyWith those concerns fixed, and tests passing again back to RTBC.
Comment #38
Gábor HojtsyComment #39
catchCommitted/pushed to 8.x, thanks!
Comment #40
Gábor HojtsyYay, superb, thanks!