I've tried to search for information around expected behavior and I'm not totally clear if what we want is possible. Ideally with Views / Facets.
I read through https://www.drupal.org/project/search_api/issues/2912242 which left me with more questions.
We have 5 languages (English, Spanish, ...).
We would like to have a views / facets list that shows all nodes of one type.
- One result per entity
- User can select languages they want to view results for
- If the entity is available in any of the selected languages, show the entity
- If the entity is available in the user language, show that version
- If the entity is not available in the user language, but is available in the default language (English), show that one
We would like user language results to show first.
So we would like:
- I'm a Spanish user
- I choose Spanish and English
- I see Spanish results first
- Then I see English results
- I don't see results for the same node in English and Spanish
Right now with an entity view (with or without facets), I get one result per translation. Each translation links to the translations page (which has a language prefix).
I'm not seeing any way around this.
Right now it appears that each result = one document in Solr. And, each document in Solr as I understand it is a translation.
It seems like there was a multilingual module and it was merged in to the main module that did things the "correct" way, but I'm not clear what that is / was.
Any clarification is appreciated.
Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 3302986_event.patch | 6.95 KB | mkalkbrenner |
| #6 | 3302986.patch | 2.62 KB | mkalkbrenner |
Comments
Comment #2
mkalkbrennerThe design decision to store one "item" per language has been taken by Search API.
#1960684: Allow filtering by "Language (with fallback)" introduced a processor to cover that fallback at index time.
Comment #3
mkalkbrennerI reviewed that processor again. It should basically work for Search API Solr, but only without fulltext searches.
To support fulltext searches there are two options:
Both ways would influence the score (term frequency, field frequency, ...)
The query for solution 1 could become very complex.
Solution 2 is easier to develop and will open the door for CLIR.
Unless CLIR based on machine translation is implemented, full text search results might be bad anyway, because you want find GREEN if you search for GRÜN or VERTE.
Anyway, with CLIR in mind, we should go for the second option.
Comment #4
damontgomery commentedThanks for the quick reply @mkalkbrenner!
I think I understand how this works and I'd like to summarize, just in case someone else finds this. I'll close the issue as well.
You commented while I was writing this, so please set status as appropriate if closing doesn't make sense.
Edit: I think I sort of understand your concerns about CLIR and full text search, but to be honest, I'm not sure I'll get to the point where I'll hit that issue. Please feel free to edit this issue in any way it's most useful for you. :) Thanks for the work and not sure if / when we'll circle back for my current project.
Scenario:
Site languages
Content
Solr / Views setup
Current behavior
User selects nothing
User selects English
User selects Spanish
User selects French
User selects English and Spanish
User selects Spanish and French
Summary of current behavior
So, basically this works that there is one document / record for every language. If a language is not available, the fallback node (My Node (EN)) will show whenever that language is selected in the filter or when the fallback language is selected.
...
Desired behavior
English user selects nothing
Spanish user selects nothing
French user selects nothing
English user selects English
English user selects Spanish
English user selects French
English user selects English and Spanish
Spanish user selects English and Spanish
English user selects Spanish and French
Summary of expected behavior
User only ever gets a single item.
Selection
Display
Conclusions
Understanding how this works is very helpful.
I think we may not be able to use Views if we want this. Or, we have to let them only select one language at a time and default that value to the current user language. Views is maybe just too limited since as far as I know, you can't really build in this branching logic. There are essentially two queries there. Maybe two views depending on the selection.
Anyway. Thanks again for all the help and hopefully this description helps someone else.
Comment #5
mkalkbrennerI basically agree with your desired behavior.
But I would not offer an exposed filter but configure a filter for that language field that is set the dynamic content languge.
I reopen the issue because I want to complete the feature for fulltext fields.
Comment #6
mkalkbrennerComment #7
mkalkbrennerI added an event to prepare the CLIR feature
Comment #9
mkalkbrennerComment #10
mkalkbrennerI made a mistake and committed a patch on an erroneous first version. Fix will be committed ASAP.
Comment #12
damontgomery commentedThanks.
I'm trying to test this locally and not seeing a difference. I'm on Search API 1.25 and Search API Solr 4.x-dev and confirmed your patch code is there.
Could you include some testing notes?
I have a `language_with_fallback` field indexed as a `string`. Also tried this with `fulltext` with the same results after removing our facet because of this notice, `Facets for fulltext fields are not yet supported. Consider converting the following field to a string or index it twice as string: language.`.
I create a view as described previously:
Add a Views exposed filter that allows multiple selections for that field. You can name it, so the name will be different, but the description is "The item language, or a language the item is a fallback for."
The reason for the exposed filter is that it's easiest for me to debug with the Views UI and doesn't require changing facets, etc.
Is there something different needed with the indexed field? I noticed you said something about fulltext fields. As noted above, I didn't see a difference on the view with string or fulltext.
Is there something different needed on the views side?
Thanks again.
Comment #13
mkalkbrennerThe patch I committed here ensures that language-specific fulltext fields are added to the indexed document for every fallback language.
That only solves the issue that you can't find the fallback document if you do fulltext searches.
The patch doesn't effect facets or exposed filters. The current behaviour you described in #4 is still the expected behaviour. That's the way it is currently designed in Search API itself.
You can get close to your desired behaviour if you don't let the user select the language but if you filter by language_with_fallback set to content language (current language selected for page).
I just used this feature on a bigger multilingual site and it worked well as expected.
Comment #14
damontgomery commentedThanks for the feedback! That makes sense.