Add TranslatedEntityProcessor

Hi Jasper,

I found a couple of things that are not up to the drupal standards, I fixed those myself in the attached patch. We'll be committing a few issues today, and I think this'll get in as well. Thanks for the patch!

@LammensJ, because the test was no in the correct namespace earlier, it wasn't executed. Can you fix the test fails?

Awesome, thanks!

Can we change the current taxonomy term processor to an entity processor and use entity::load instead? If possible useing loadMultiple as well to have less individual loads.

You can actually find it through the index. Since a field cannot be shared across entity types you can look up the entity type in the storage of the field.
So: facet processor -> datasource -> index -> field -> storage -> fetch entity type. Unless I'm missing something here? Discussed this briefly with drunkenmonkey and borisson

It won't always be a view, we also support drupal core and search_api_page as facet sources, they don't have that.

Hadn't seen this issue so I made another try at this in https://www.drupal.org/node/2760401.

I made some small tweaks to #20:
- added . at the end of a comment
- load entity_type the same way as in ListItemProcessor::build()
- don't set setDisplayValue twice

Quick questions though: why do we have three processors (entity, node, term) while they're all entities?

Quick questions though: why do we have three processors (entity, node, term) while they're all entities?

That makes sense, it should be sufficient if we only have an entity processor.

Guess I'll have to mock the language_manager and entity_type.manager aswell.

Injected services:
- language_manager
- entity_type.manager

WIP, still needs testing.

Mocking all dependencies is tricky. But I noticed $source->getIndex() is based upon SearchApiFacetSourceInterface and thus only available for SearchApiViews, correct?

I fixed some coding style things and added extra documentation.

This looks great overall. I'd love to hear from @LammensJ if this also works in his usecase, if it does, we can commit this.

Thanks for the review!

Too bad we have to rely on the SearchApiFacetSourceInterface class to get the entity type. I guess that's an api change in Search Api if we want to remove that if.

That is too bad, I agree. But this is not because of search api, but because we also support creating facets for drupal core. And because core's search doesn't have an "index" concept we have write the check.

I'll have a look at the test-failures tonight and when those are resolved, we can commit this. Thanks for the review and for removing the switch @LammensJ, that looks great!

Awesome, committing this later today.

Committed, thanks everyone!