search_api_elasticsearch icon indicating copy to clipboard operation
search_api_elasticsearch copied to clipboard

Entity translation support

Open tappleby opened this issue 9 years ago • 4 comments

Based on our discussion on twitter, it would be nice to have support for entity translation (et).

The Solr and DB backends have support via the search_api_et module. I was able to get data indexed using the et. module by modifying the id schema type. My issue with the mentioned module is a document is created per language and put into the same index:

image

The Solr et module uses dynamic fields with the document language added to translatable fields (this solves invalid inverse document frequency issues).

When using the search_api_page module results are filtered using the search_api_language condition.

An index per language feels like the most flexible approach although I can see some use cases for field per language.

tappleby avatar Jun 15 '15 14:06 tappleby

@VeggieMeat you mentioned using aliases instead of having to maintain multiple views. I am curious how this would look for mapping to the correct index based on the current users language (or perhaps across multiple). Is this logic handled on the drupal or ES side (not too familiar with ES aliases)?

tappleby avatar Jun 15 '15 15:06 tappleby

The primary reason for aliases (see #76) is to avoid the downtime issues caused by Search API's reindex process as well as the rebuilds required when changing index configuration or mappings in Elasticsearch.

My thinking is that, on a multilingual site, language specific aliases would be maintained, such as my_sapi_index_. The format for aliases in #76 is for an alias of my_sapi_index to point to my_sapi_index_<created_time>. The idea is for configuration or mapping updates or for re-indexing to create a new index, copy data as necessary, and then re-point the alias when the process is complete.

Another benefit is that aliases can point to multiple indices, or they can even point to filtered indices. In this case, my thinking was a global alias would be provided that would point across all language indices and be used by default. We could provide an option in the Search API Views configuration to use the global alias or the language-specific alias.

VeggieMeat avatar Jun 16 '15 10:06 VeggieMeat

I think the aliases will be useful. As far as the Search API Views configuration, the ideal use case for my current setup would be to dynamically set the alias/index based on the views "Item Language" filter criteria.

Its still a bit unclear to me how multiple elasticsearch index's per language would be maintained. Would these be managed as separate drupal SearchApiIndex? Or could a single drupal index map to multiple elasticsearch indexes behind the scenes?

tappleby avatar Jun 16 '15 17:06 tappleby

A single Drupal index can map to multiple Elasticsearch indexes.

VeggieMeat avatar Jun 16 '15 17:06 VeggieMeat