I have a site that is using Entity Translation where a few of the fields on the Content Type are translatable. I'm using Search API Views to display the results and filter by the current language (or language neutral). Using the Search API Entity Translation and Search API Entity Translation Solr search modules I am able to use search keywords to get the correct results, but when the results are displayed, I see the source language for the field instead of the current language.
As an example: I have a content type with a translatable "Display Title" field. The source language is Spanish (es). Say that the title is "Test title - Spanish" and then I add a translation in German (de), with the translation "Test title - German".
When the current language is Spanish, I can search for "test" and see the "Test title - Spanish" result returned. If I search for "german" then no results are returned. This seems to work as I would expect because for the current language there are no results matching "german". If I switch the current language to German, I can search for "test" and "german" and the result is returned, however the title is displayed as "Test title - Spanish" even though my current language is German.
From what I can tell, of what is supposed to happen, \SearchApiEtDatasourceController::loadItems(); is supposed to load the entity using the language of the returned result, however when using Search API Views I always end up in // Case 2 - no language in item ID. . I think this is because in \SearchApiViewsQuery::get_result_wrappers(); it is passing only the entity id, not the search_api_id to $index->loadItems(); . I'm unclear if this is a bug in Search API Views, or if that is the expected parameter of loadItems(); , however I was able to get the correct result by changing $load_items[$row->entity] = $row_index; to $load_items[$row->_entity_properties['search_api_id']] = $row_index; in search_api/contrib/search_api_views/includes/query.inc.
Another potentially relevant note about my configuration is that "Retrieve result data from Solr" is disabled for my Search API Server. I tested turning it on, and while that gets the correct content in the view, it has all the applied transformations, for example it displays "test title - german" instead of "Test title - German".
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | search_api_views-display_translated_field_2911927-2.patch | 1.11 KB | jojonaloha |
Comments
Comment #2
jojonaloha commentedAttached is a patch with the change to
\SearchApiViewsQuery::get_result_wrappers();Comment #3
drunken monkeyThanks a lot for reporting this issue!
I don't have a multilingual test site set up, so I unfortunately can't test this myself. However, as far as I can see, this should already work as expected. If you look at
SearchApiViewsQuery::addResults(), you see that the result index (which should be the item ID – so, entity ID plus language, in your case) is already set as the$row->entityvalue – as it should be. (It's a bit confusing, I know – the reason is that we only later allowed indexing of non-entities, so some parts of the module still, at least in nomenclature, deal only with "entities" and "entity IDs".)Therefore, this should already be what's passed to
$this->index->loadItems()later in the code (either inaddResults()itself or inget_result_wrappers()). I don't know why this isn't working. Your patch would only work for the Solr backend, in any case, so can't be used to fix this. Please try debugging to see where and why the wrong value is set. In general, all the IDs in the module should be the "combined item IDs", not pure entity IDs, when using a multilingual datasource.This means that you have processors enabled on your index which usually shouldn't be used together with Solr. "Ignore case", "Tokenizer", etc. can all be taken care of much better by Solr itself – which will also result in the correct (original) values being returned from Solr.
Comment #4
benstallings commented