Use core's language fallback system

Interesing idea. But I wonder if the implementation should really depend on the language_hierarchy module. There's no activity for more than a year.

BTW we already have soemething in place for locales: "de-AT" falls back to "de".

Do you know of any integration with Views using such language fallbacks?

Anyway, we can add something to our module.

Can you describe some concrete examples as a guideline for implementing it?

just an idea, we have similar use case in our solution. We did the fallback check on query.

I think that this should be solved by Search API itself and not the backend.
The simple approach would be to contain the targeted AND the fallback language in the Search API Query. The fallback language(s) should be added automatically if requested.

In what way would that be different from #1960684: Allow filtering by "Language (with fallback)" or the (WIP) patch proposed there?
(Having this processor directly in Search API instead of the CLIR module would of course be an option either way.)

Great to hear, thanks for sharing!
Maybe ping them about adding the “Search API” ecosystem to the project description so it will be listed in our ecosystem.

Hm, not sure whether that’s the best approach. If I understand this correctly (didn’t try it out) this will, e.g., when indexing an English node also index a copy of that node as French if there is no French translation (depending on the fallback settings, of course)?
Then apart from bloating the index unnecessarily, it also seems this would mean that Solr would try to do French text preprocessing on the English text content of that node on indexing, right? Needless to say, this wouldn’t work properly.
I also don’t see a big market for varying fallback sequences by entity, but even so, it seems that could equally well be accomplished by switching the current missing_translations property for a fallback_for_languages property that will be filtered for as a fallback for search_api_language at search time (please shout if I’m not making any sense here). However, while this would be more flexible, the downside would be that you’d then have to search all languages at search time and just let that filter do the filtering – decreasing performance, as long as there’s more than a couple of languages.

All in all, I still think our approach in the CLIR issue is the better one. People who want the other one can just use the entity_language_fallback module right now, nothing preventing you from doing that. (You can probably just search/replace the datasource ID in the exported index config and re-import, that should give you the exact same index just with the added language fallback functionality.)