The initial goal of this module is to make multilingual content managed by the entity_translation.module somehow searchable via the search_api.module. This basically works. But in a very basic and crude way: The module just offers a search field containing renderings of all translations of an entity concatenated in one fulltext field. Works. But is very very very crude with a number of serious drawbacks (no possibility to search only in a specific language, therefore potential confusing mismatches in search results, fully rendered entity search only (no field-specific et-multilingual search), and probably other quirks and drawbacks.)
The short term goal of this module is to provide a better basic way of supporting et-multilingual entities in Search API, by having it at least providing some possibility to distinguish the different translations for search, and therefore make it language-aware: The user should be able to search through and find content in only exactly those languages he wishes to search in.
For this to work, the rather stupid concatenation of all translations has to be refined.
There are multiple ways to do this - and you're welcome to add good ways to this list!
Currently, i see two realistic ways to support language aware search for field translation / entity translation content via search_api:
(based on the initial discussion at http://drupal.org/node/1323168#comment-5340212 - i already skipped the ways that have been ruled out there)
A) Somehow declaring and using an entity/search property that can carry multiple values, one for each translation's full entity rendering, somewhere in the workings of:
langvalue = 'search_api_language-en my english content'
langvalue = 'search_api_language-de mein deutscher inhalt'
langvalue = 'search_api_language-es mi contenido español'
Not shure if that would work.
This would mean medium work all contained in a contrib module extending search api, very little config work if done correctly, clean and scaling with changes in a site's language settings. But is that possible (see threaded comment for details)?
=> Possible way?
B) Adding additional language-aware item types for each entity type, by customizing the Search API data source controller (based on SearchApiEntityDataSourceController) for the new item types a bit. This would allow for the data source to "know" of the translations and have their search item IDs to carry the language code, for example.
=> Possible Way?
Let us discuss those possible ways towards a language-aware support of Entity Translations in Search API.
It would help a lot to know from you ...
* Do you need this language-awareness for this combination of modules at all?
* What's your preference? Why?
* Do you see other ways of achieving this goal?
* Could you help with the implementation?